标签：Java 池内 并发 任务 线程 误区 QPS BlockingQueue
图片
来源：https://zhenbianshu.github.io
前言
由于线程的创建和销毁对操作系统来说都是比较重量级的操作，所以线程的池化在各种语言内都有实践，当然在 Java 语言中线程池是也非常重要的一部分，有 Doug Lea 大神对线程池的封装，我们使用的时候是非常方便，但也可能会因为不了解其具体实现，对线程池的配置参数存在误解。
我们经常在一些技术书籍或博客上看到，向线程池提交任务时，线程池的执行逻辑如下：
当一个任务被提交后，线程池首先检查正在运行的线程数是否达到核心线程数，如果未达到则创建一个线程。
如果线程池内正在运行的线程数已经达到了核心线程数，任务将会被放到 BlockingQueue 内。
如果 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 (;
标签：Java,池内,并发,任务,线程,误区,QPS,BlockingQueue 来源： https://blog.csdn.net/msw609547903/article/details/121373109
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。