盘点 Java 线程池配置的常见误区(1)

• 如果 BlockingQueue 已满，线程池将会尝试将线程数扩充到最大线程池容量。

• 如果当前线程池内线程数量已经达到最大线程池容量，则会执行拒绝策略拒绝任务提交。

流程如图（摘自美团技术博客）：

流程描述没有问题，但如果某些点未经过推敲，容易导致误解，而且描述中的情境太理想化，如果配置时不考虑运行时环境，也会出现一些非常诡异的问题。

核心池

---

线程池内线程数量小于等于 coreSize 的部分我称为核心池，核心池是线程池的常驻部分，内部的线程一般不会被销毁，我们提交的任务也应该绝大部分都由核心池内的线程来执行。

线程创建时机的误解

有关核心池最常见的一个误区是没搞清楚核心池内线程的创建时机，这个问题，我觉得甩 10% 的锅给 Doug Lea 大神应该不算过分，因为他在文档里写道 “If fewer than corePoolSize threads are running, try to start a new thread with the given command as its first task”，其中 “running” 这个词就比较有歧义，因为在我们理解里 running 是指当前线程已被操作系统调度，拥有操作系统时间分片，或者被理解为正在执行某个任务。

基于以上的理解，我们很容易就认为如果任务的 QPS 非常低，线程池内线程数量永远也达不到 coreSize。即如果我们配置了 coreSize 为 1000，实际上 QPS 只有 1，单个任务耗时 1s，那么核心池大小就会一直是 1，即使有流量抖动，核心池也只会被扩容到 3。因为一个线程每秒执行执行一个任务，刚好不用创建新线程就足以应对 1QPS。

创建过程

但如果简单设计一个测试，使用 jstack 打印出线程栈并数一下线程池内线程数量，会发现线程池内的线程数会随着任务的提交而逐渐增大，直到达到 coreSize。

因为核心池的设计初衷是想它能作为常驻池，承载日常流量，所以它应该被尽快初始化，于是线程池的逻辑是在没有达到 coreSize 之前，每一个任务都会创建一个新的线程，对应的源码为：

public void execute(Runnable command) {

…

int c = ctl.get();

if (workerCountOf© < corePoolSize) { // workerCountOf() 方法是获取线程池内线程数量

if (addWorker(command, true))

return;

c = ctl.get();

}

…

}

而文档里的 running 状态也指的是线程已经被创建，我们也知道线程被创建后，会在一个 while 循环里尝试从 BlockingQueue 里获取并执行任务，说它正在 running 也不为过。

基于此，我们对一些高并发服务进行的预热，其实并不是期望 JVM 能对热点代码做 JIT 等优化，对线程池、连接池和本地缓存的预热才是重点。

BlockingQueue

---

BlockingQueue 是线程池内的另一个重要组件，首先它是线程池”生产者-消费者”模型的中间媒介，另外它也可以为大量突发的流量做缓冲，但理解和配置它也经常会出错。

运行模型

最常见的错误是不理解线程池的运行模型。首先要明确的一点是线程池并没有准确的调度功能，即它无法感知有哪些线程是处于空闲状态的，并把提交的任务派发给空闲线程。线程池采用的是”生产者-消费者”模式，除了触发线程创建的任务（线程的 firstTask）不会入 BlockingQueue 外，其他任务都要进入到 BlockingQueue，等待线程池内的线程消费，而任务会被哪个线程消费到完全取决于操作系统的调度。

对应的生产者源码如下：

public void execute(Runnable command) {

…

if (isRunning© && workQueue.offer(command)) { isRunning() 是判断线程池处理戚状态

int recheck = ctl.get();

if (! isRunning(recheck) && remove(command))

reject(command);

else if (workerCountOf(recheck) == 0)

addWorker(null, false);

}

…

}

对应的消费者源码如下：

private Runnable getTask() {

for (;😉 {

…

Runnable r = timed ?

workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :

workQueue.take();

if (r != null)

return r;

…

}

}

BlockingQueue 的缓冲作用

基于”生产者-消费者”模型，我们可能会认为如果配置了足够的消费者，线程池就不会有任何问题。其实不然，我们还必须考虑并发量这一因素。

设想以下情况：有 1000 个任务要同时提交到线程池内并发执行，在线程池被初始化完成的情况下，它们都要被放到 BlockingQueue 内等待被消费，在极限情况下，消费线程一个任务也没有执行完成，那么这 1000 个请求需要同时存在于 BlockingQueue 内，如果配置的 BlockingQueue Size 小于 1000，多余的请求就会被拒绝。

最后

最后，强调几点：

• 1. 一定要谨慎对待写在简历上的东西，一定要对简历上的东西非常熟悉。因为一般情况下，面试官都是会根据你的简历来问的； 能有一个上得了台面的项目也非常重要，这很可能是面试官会大量发问的地方，所以在面试之前好好回顾一下自己所做的项目；
• 2. 和面试官聊基础知识比如设计模式的使用、多线程的使用等等，可以结合具体的项目场景或者是自己在平时是如何使用的；
• 3. 注意自己开源的Github项目，面试官可能会挖你的Github项目提问；

我个人觉得面试也像是一场全新的征程，失败和胜利都是平常之事。所以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！

以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。

面试答案

未来，继续加油！

以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。

面试答案

[外链图片转存中…(img-5nSYNoK4-1714763488708)]

[外链图片转存中…(img-ocX1rr6q-1714763488709)]

[外链图片转存中…(img-goK6NOzd-1714763488709)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录