Java 并发：ThreadPoolExecutor 参数到底怎么配

很多人用线程池图省事，直接 Executors.newFixedThreadPool(10) 或 newCachedThreadPool()，上线后要么内存溢出，要么请求被莫名其妙丢弃，排查半天才发现是线程池参数没配对。阿里的《Java 开发手册》甚至明确禁止用 Executors 快捷方法创建线程池。这篇讲清楚 ThreadPoolExecutor 七个参数各自的作用、任务进来后的执行流程，以及生产环境到底该怎么配。

一、为什么不用 Executors 快捷方法

先看 Executors.newFixedThreadPool 的实现：

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
            0L, TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>()); // 无界队列！
}

问题出在 LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE，等于无界。当任务生产速度超过消费速度，队列会无限堆积，最终 OOM。newCachedThreadPool 更极端，最大线程数是 Integer.MAX_VALUE，突发流量下会创建海量线程直接压垮机器。所以要手动 new，把每个参数都攥在手里。

二、七个参数逐个拆解

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,                              // corePoolSize 核心线程数
    8,                              // maximumPoolSize 最大线程数
    60L, TimeUnit.SECONDS,          // keepAliveTime 空闲线程存活时间
    new ArrayBlockingQueue<>(200),  // workQueue 有界任务队列
    new ThreadFactoryBuilder()      // threadFactory 线程工厂，给线程起名
        .setNameFormat("order-pool-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // handler 拒绝策略
);

• corePoolSize：常驻线程数，即使空闲也不回收（除非开了 allowCoreThreadTimeOut）。
• maximumPoolSize：线程数上限，只有队列满了才会创建到这个数。
• keepAliveTime：超过核心数的那些线程，空闲多久后被回收。
• workQueue：核心线程都忙时，新任务先进这个队列排队，必须用有界队列。
• threadFactory：给线程起有意义的名字，出问题看线程栈时能一眼定位是哪个池。
• handler：队列满且线程数到上限后，新任务怎么处理。

三、任务进来后的执行流程（最关键）

这是最反直觉的地方。一个任务提交后，线程池的判断顺序是：

1. 当前线程数 < corePoolSize → 直接创建新线程执行，哪怕有空闲核心线程也照样创建，直到填满核心数。
2. 线程数已达 corePoolSize → 任务进队列排队。
3. 队列满了 → 才创建新线程，直到达到 maximumPoolSize。
4. 队列满且线程数已达 maximum → 触发拒绝策略。

划重点：是"先塞队列，再扩线程"。所以如果你用了无界队列，第 3 步永远到不了，maximumPoolSize 形同虚设。这就是为什么 newFixedThreadPool 的 max 参数没有任何意义。

四、四种拒绝策略怎么选

队列满、线程满之后，JDK 内置四种处理方式：

// 1. AbortPolicy（默认）：直接抛 RejectedExecutionException
new ThreadPoolExecutor.AbortPolicy();
// 2. CallerRunsPolicy：让提交任务的线程自己执行，相当于天然限流
new ThreadPoolExecutor.CallerRunsPolicy();
// 3. DiscardPolicy：默默丢弃新任务，不抛异常（危险，任务无声消失）
new ThreadPoolExecutor.DiscardPolicy();
// 4. DiscardOldestPolicy：丢掉队列里最老的任务，再尝试提交
new ThreadPoolExecutor.DiscardOldestPolicy();

生产上最实用的是 CallerRunsPolicy：任务多到处理不过来时，让调用方线程（比如 Tomcat 的请求线程）亲自去跑任务，调用方被拖慢就自然降低了提交速度，形成背压反馈，既不丢任务也不会雪崩。如果任务不能丢，也可以自定义 handler 把任务落库或写入 MQ 后续重试。

五、参数到底配多大

没有万能公式，取决于任务是 CPU 密集还是 IO 密集：

• CPU 密集型（加密、压缩、计算）：线程数 ≈ CPU 核数 + 1。线程再多只会增加上下文切换开销。
• IO 密集型（调接口、查库、读文件）：线程大部分时间在等 IO，可以配更多，经验公式 核数 * (1 + 平均等待时间/平均计算时间)。比如 8 核、任务 90% 时间在等 IO，可以配到几十。

队列大小则要结合业务能接受的排队延迟和内存来定。一个务实做法：先按经验配，再上线用监控盯着调。

// 暴露线程池运行指标，接入 Prometheus / 日志定期打印
ScheduledExecutorService monitor = Executors.newSingleThreadScheduledExecutor();
monitor.scheduleAtFixedRate(() -> {
    System.out.printf("活跃=%d 池大小=%d 队列积压=%d 已完成=%d%n",
        executor.getActiveCount(),
        executor.getPoolSize(),
        executor.getQueue().size(),
        executor.getCompletedTaskCount());
}, 0, 5, TimeUnit.SECONDS);

队列长期积压说明消费能力不足，要加线程或优化任务耗时；活跃数长期打满 max 说明池子偏小。用数据说话，别拍脑袋。

六、别忘了优雅关闭

线程池用完要关，否则非守护线程会阻止 JVM 退出：

executor.shutdown(); // 不再接收新任务，等已提交任务跑完
if (!executor.awaitTermination(30, TimeUnit.SECONDS)) {
    executor.shutdownNow(); // 超时后强制中断
}

shutdown() 是温和的，shutdownNow() 会给正在跑的线程发中断信号并返回未执行的任务列表。

七、小结

• 别用 Executors 快捷方法，手动 new ThreadPoolExecutor 并用有界队列，防 OOM。
• 记住执行顺序：核心线程 → 进队列 → 扩到最大线程 → 拒绝策略。是"先排队再扩容"。
• 无界队列会让 maximumPoolSize 失效，这是最常见的误配。
• 拒绝策略生产首选 CallerRunsPolicy，靠背压限流；不能丢的任务自定义 handler 落库重试。
• CPU 密集配核数+1，IO 密集可放大；配完一定要上监控持续调。

一句话记忆：线程池的坑几乎都出在"队列无界"和"不懂先排队再扩容"这两点上，把这两条想明白，参数就配对了一大半。