一、并发编程的目的
核心目标：通过多线程技术提升程序执行效率，但需在 合理线程数量 和 资源限制 之间找到平衡。
误区：单纯增加线程数量可能导致性能下降（如上下文切换开销、资源竞争）。
二、并发编程的三大挑战与解决方案
1. 上下文切换（Context Switching）
• 问题描述：
线程频繁切换导致CPU时间浪费（每次切换约1-10微秒），降低程序实际吞吐量。
示例：100个线程竞争1个CPU核心时，大量时间用于切换而非执行任务。
• 解决方案：
• 优化线程池配置：
◦ IO密集型任务：增大线程数（如 线程数 = CPU核心数 × 2）。
◦ CPU密集型任务：限制线程数等于CPU核心数。
java // 合理配置线程池参数 ExecutorService executor = new ThreadPoolExecutor( Runtime.getRuntime().availableProcessors(), // 核心线程数 Runtime.getRuntime().availableProcessors() * 2, // 最大线程数 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100) );
• 使用协程（Coroutine）：
通过轻量级线程（如Kotlin协程、Go的goroutine）减少切换开销。
kotlin // Kotlin协程示例 fun main() = runBlocking { repeat(1000) { launch { // 启动协程而非线程 delay(100) println("Task $it completed") } } }
2. 死锁（Deadlock）
• 问题描述：
多个线程因互相持有对方所需资源而永久阻塞。
必要条件：互斥、占有且等待、不可抢占、循环等待。
• 解决方案：
• 破坏死锁条件：
◦ 按顺序获取锁：全局定义锁的获取顺序，避免循环等待。
◦ 超时机制：使用 tryLock() 设置获取锁的超时时间。
```java
ReentrantLock lockA = new ReentrantLock();
ReentrantLock lockB = new ReentrantLock();
// 统一获取顺序：先lockA，后lockB
if (lockA.tryLock(1, TimeUnit.SECONDS)) {
try {
if (lockB.tryLock(1, TimeUnit.SECONDS)) {
try { /* 临界区 */ }
finally { lockB.unlock(); }
}
} finally { lockA.unlock(); }
}
```
• 死锁检测与恢复：
◦ 使用 jstack 分析线程转储，定位死锁链并强制终止线程。
3. 资源限制（Hardware/Software Constraints）
• 问题描述：
• 硬件限制：CPU核心数、内存带宽、磁盘IO速度。
• 软件限制：数据库连接池大小、Socket连接数。
• 解决方案：
• 垂直扩展（Scale Up）：升级硬件（如增加CPU核心、使用SSD）。
• 水平扩展（Scale Out）：通过分布式系统分摊负载（如Kafka分片、Redis集群）。
• 资源池化：复用资源减少创建开销（如数据库连接池、线程池）。
java // 数据库连接池配置（HikariCP） HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/db"); config.setUsername("user"); config.setPassword("password"); config.setMaximumPoolSize(10); // 控制最大连接数 HikariDataSource dataSource = new HikariDataSource(config);
三、总结与最佳实践
-
平衡线程数量：
• 根据任务类型（CPU/IO密集型）动态调整线程池参数。
• 避免无限制创建线程（通过线程池约束）。 -
预防死锁：
• 统一锁的获取顺序，引入超时和重试机制。 -
资源管理：
• 硬件资源不足时优先优化代码，其次考虑扩展硬件或分布式方案。
• 使用池化技术减少资源创建销毁开销。 -
性能监控：
• 使用工具（如Arthas、JFR）实时监控线程状态和资源使用率。
• 定期分析日志和线程转储，定位潜在瓶颈。
关键思路：
• 并发 ≠ 并行：合理线程数需结合任务类型和硬件资源。
• 避免过度设计：在正确性前提下优化性能，优先解决主要瓶颈。
• 分治策略：将大任务拆分为独立子任务，减少共享状态和锁竞争。 。
