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()); // 无界队列！
}

问题出在哪里？LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE，实际上是一个无界队列。当任务生产速度超过消费速度时，队列会无限堆积，最终导致 OOM。newCachedThreadPool 更加极端，最大线程数为 Integer.MAX_VALUE，突发流量下会创建海量线程直接压垮机器。因此，手动创建线程池，把每个参数都牢牢控制在手中，才是正确的做法。

二、七个参数逐个拆解

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 将任务写入数据库或消息队列，后续再重试处理。

五、参数到底配多大

没有万能公式，取决于任务是 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);

队列长期积压说明消费能力不足，需要增加线程或优化任务耗时；活跃数长期打满 maximum 说明线程池偏小。用数据说话，避免凭感觉拍脑袋。

六、别忘了优雅关闭

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

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

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

七、小结

• 避免使用 Executors 快捷方法，手动 new ThreadPoolExecutor 并配合有界队列，防止 OOM。
• 牢记执行顺序：核心线程 → 进入队列 → 扩到最大线程 → 触发拒绝策略。即“先排队再扩容”。
• 无界队列会导致 maximumPoolSize 失效，这是最常见的参数误配。
• 拒绝策略生产环境首选 CallerRunsPolicy，利用背压实现限流；不能丢失的任务应自定义 handler 落库重试。
• CPU 密集型配置核数 + 1，IO 密集型可适当放大；配置完成后务必通过监控不断调优。

一句话总结：线程池的坑几乎都出在“队列无界”和“不懂先排队再扩容”这两点上，把这两条理解透彻，参数就配置对了一大半。