Java 线程池的核心参数怎么设置？队列越大越安全吗？

知识点详解：任务进入线程池后，到底先排队还是先扩容

先用一组小参数把顺序走一遍

假设一个线程池的核心线程数是 2，最大线程数是 4，队列容量也是 2。我们连续提交 7 个耗时任务，并假设前面的任务还没有完成。

前两个任务交给新建的核心线程；第 3、4 个进入队列；第 5、6 个因为队列已满，分别交给新建的非核心线程；第 7 个才触发拒绝。

所以，最大线程数不是「一有等待任务就扩到这里」。核心线程达到数量以后，线程池会先尝试入队。这也是为什么只增大 maximumPoolSize，有时候看不到任何变化。

几个参数各自解决什么问题

corePoolSize 决定优先建立多少工作线程，maximumPoolSize 限制最多能有多少。workQueue 存放暂时不能处理的任务；keepAliveTime 通常用于回收空闲的非核心线程，也可以配置核心线程超时。ThreadFactory 负责线程名称等创建细节，拒绝处理器则决定接不下任务时怎么办。

我们尤其要注意无界队列。只要入队还能成功，线程池就不会因为积压去扩到最大线程数。问题从「线程不够」变成了「队列越堆越长」。队列里的请求、参数和上下文，也都占用内存。

怎么把参数和业务限制对起来

如果任务主要做计算，增加太多线程只会让它们争抢 CPU。这里应该看容器实际获得的 CPU 配额，而不只是宿主机核数。如果任务经常等待远端服务，可以适当增加并发，但下游连接池和服务容量仍然是上限。

队列容量可以从允许的排队时间反推一个初始范围。例如假设稳定处理能力是每秒 100 个任务，最多愿意让任务等待半秒，那么 50 个积压任务已经值得警惕。这只是估算，不是保证；任务耗时有波动，还需要压测。

同时记录提交、开始执行和完成的时间。接口总耗时变长，可能并不是执行变慢，而是在队列里等了太久。

拒绝策略要让调用方知道发生了什么

AbortPolicy 抛出异常；CallerRunsPolicy 在提交任务的线程里执行，可能通过拖慢提交者来形成反馈；两种丢弃策略则会丢掉任务。

不能看见「调用方执行」就认为它一定安全。如果提交者是事件循环或关键请求线程，这会把慢任务带回原来的链路。重要任务也不应静默丢弃：要么明确返回繁忙，要么转入可恢复的持久化任务系统。

上线前要主动压到队列满，检查拒绝是否被处理、过期任务能否取消、停机时能否完成或妥善移交。只测正常吞吐，测不出这些问题。

本题机制参考：JDK 25 ThreadPoolExecutor、JDK 虚拟线程指南。

面试官继续追问

CPU 密集任务有没有万能线程数公式？

没有。核数只能给初始范围，任务切换、运行时开销、CPU 配额和其他负载都会影响结果。要用同一批任务比较吞吐与尾部延迟。

虚拟线程是不是让这些限制消失了？

不是。虚拟线程降低了大量等待任务使用线程的成本，但不会增加数据库连接、CPU 或远端服务容量。限制并发应放在稀缺资源入口，不能把虚拟线程当作无限容量。

队列空了就说明系统健康吗？

也不一定。可能是任务被拒绝了，或调用方已经不再提交。要把成功完成量、拒绝数和超时一起看。

面试速记卡

• 接纳顺序：核心线程 → 入队 → 扩到最大线程数 → 拒绝。
• 大队列会增加等待和内存，不等于增加处理能力。
• 无界队列通常使最大线程数失去扩容作用。
• 线程数看任务与资源；队列看等待期限；拒绝必须可见。