V12119w1. 线程池基础概念与核心价值
第一次接触线程池是在处理一个订单处理系统时，系统高峰期每秒要处理300+订单请求，直接new Thread()的方式导致系统瞬间创建上千线程，最终引发OOM崩溃。这个惨痛教训让我深刻认识到线程池的必要性。
线程池本质上是一种线程管理机制，它通过预先创建并维护一组可复用的工作线程，避免了频繁创建和销毁线程的开销。就像餐厅里固定数量的服务员，比起每来一个顾客就临时招聘再解雇，显然前者效率更高且管理成本更低。
Java中的线程池实现主要基于Executor框架，其核心优势体现在三个方面：
- 资源控制：通过限制最大线程数防止系统过载
- 性能提升：线程复用降低创建/销毁开销（实测线程复用可使QPS提升40%+）
- 管理便捷：统一的任务队列和拒绝策略机制
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 线程池核心参数详解
2.1 构造参数解析
以ThreadPoolExecutor的完整构造函数为例：
java复制public ThreadPoolExecutor(
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
- corePoolSize（核心线程数）：就像餐厅的正式员工，即使空闲也不会被裁撤。根据服务器CPU核数设置是常见做法（N+1原则）
- maximumPoolSize（最大线程数）：包含核心线程和临时线程。电商大促时我们设置为coreSize的3倍
- keepAliveTime（空闲存活时间）：临时线程的空闲存活时长，设置过短会导致频繁创建，过长浪费资源
- workQueue（任务队列）：推荐使用有界队列如ArrayBlockingQueue，无界队列可能导致OOM
2.2 四种拒绝策略对比
| 策略类 | 行为 | 适用场景 |
|---|---|---|
| AbortPolicy | 直接抛出RejectedExecutionException | 需要严格保证不丢失任务的场景 |
| CallerRunsPolicy | 由调用线程直接执行任务 | 适合能容忍短暂延迟的场景 |
| DiscardPolicy | 静默丢弃新任务 | 日志采集等可丢失场景 |
| DiscardOldestPolicy | 丢弃队列最老任务 | 实时性要求高的场景 |
实际项目中我们通常自定义拒绝策略，比如触发告警或将任务持久化到Redis
3. 线程池工作原理解析
3.1 任务处理流程
- 提交任务时首先检查核心线程是否都在忙
- 核心线程忙则将任务放入队列（除非使用SynchronousQueue）
- 队列满时才会创建临时线程（直到达到maxPoolSize）
- 所有线程都在忙且队列满时触发拒绝策略
这个流程有个反直觉的点：不是先创建线程到maxPoolSize再用队列，而是先用队列。这会导致某些场景下线程数增长不及时，可以通过重写execute方法优化。
3.2 线程创建与回收
- 核心线程默认不会超时回收（可通过allowCoreThreadTimeOut设置）
- 临时线程在keepAliveTime时间内无任务即被回收
- 使用自定义ThreadFactory可以给线程命名便于监控
4. 五种预置线程池对比
4.1 FixedThreadPool vs CachedThreadPool
java复制// 固定大小线程池
ExecutorService fixedPool = Executors.newFixedThreadPool(10);
// 可缓存线程池
ExecutorService cachedPool = Executors.newCachedThreadPool();
| 类型 | 核心线程数 | 最大线程数 | 队列类型 | 特点 |
|---|---|---|---|---|
| FixedThreadPool | 固定 | 同核心 | LinkedBlockingQueue | 适合负载稳定的场景 |
| CachedThreadPool | 0 | Integer.MAX_VALUE | SynchronousQueue | 适合短时突发流量 |
| SingleThreadExecutor | 1 | 1 | LinkedBlockingQueue | 保证顺序执行 |
| ScheduledThreadPool | 指定 | Integer.MAX_VALUE | DelayedWorkQueue | 定时任务专用 |
| WorkStealingPool | 并行度 | 并行度 | 无队列 | ForkJoinPool实现 |
阿里开发手册明确禁止使用Executors创建线程池，推荐通过ThreadPoolExecutor构造，原因在于无界队列可能导致OOM
5. 线程池实战技巧
5.1 参数调优经验
- IO密集型：核心线程数=2*CPU核数（网络请求、DB操作等）
- CPU密集型：核心线程数=CPU核数+1（加解密、计算等）
- 混合型：拆分不同线程池处理，或使用公式：N*(1+WT/ST)
其中WT是等待时间，ST是执行时间。例如某接口平均执行时间50ms，等待DB响应150ms，则线程数=8*(1+150/50)=32
5.2 监控与问题排查
推荐监控指标：
java复制ThreadPoolExecutor executor = ...;
// 当前活跃线程数
executor.getActiveCount();
// 历史最大线程数
executor.getLargestPoolSize();
// 已完成任务数
executor.getCompletedTaskCount();
常见问题排查：
- 任务堆积：检查队列大小与消费速度
- 线程数不增长：确认队列未满（特别是LinkedBlockingQueue）
- 内存泄漏：注意线程中引用的对象生命周期
6. Spring中的线程池应用
6.1 @Async配置示例
java复制@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {
@Override
public Executor getAsyncExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(5);
executor.setMaxPoolSize(10);
executor.setQueueCapacity(100);
executor.setThreadNamePrefix("Async-");
executor.initialize();
return executor;
}
}
6.2 事务注意事项
- 异步方法上的@Transactional注解通常无效
- 需要手动传递事务上下文或使用TransactionTemplate
- 跨线程的ThreadLocal变量会丢失
7. 线程池的演进与最佳实践
7.1 Java 8增强
- newWorkStealingPool()利用ForkJoinPool
- CompletableFuture内置通用线程池
7.2 生产环境建议
- 使用有界队列并设置合理的拒绝策略
- 为不同业务创建独立线程池（避免相互影响）
- 通过APM工具监控线程池状态
- 线程池销毁前调用shutdown()平滑关闭
在最近的一个风控系统中，我们采用多级线程池设计：
- 第一层：4个FixedThreadPool处理不同优先级请求
- 第二层：CachedThreadPool执行具体风控规则
- 共享一个Sentinel限流控制器
这种设计使系统在双11期间保持稳定，峰值QPS达到12万，线程数控制在800以内。