【补档】线程池参数千万不要这样设置，一个全新的大坑，要注意！
你好呀，我是来补档的歪师傅。
昨天发布的同名文章忘记打“原创”标识了，所以重发一次。
如果看完后觉得有不清楚的地方，可以看看昨天这篇文章的评论区：《线程池参数千万不要这样设置，坑得我整篇文章都写错了，要注意！》
看这篇文章，你只需要抓住三个点：
设置线程池阻塞队列的长度时，至少保证阻塞队列本身的长度大于一次提交进来的任务数，而不要做出线程数加上队列长度才勉强容纳单批次任务数，这么极端的长度参数。 结论不重要，重要的是寻找结论的过程。 如果觉得看起来很迷糊，自信一点，不要怀疑自己，就是歪师傅写的不好，评论区大胆的留下“写的什么垃圾玩意”就行。
你好呀，我是歪歪。
先给大家道个歉：
上周不是发布了这篇文章嘛：《三个烂怂八股文，变成两个场景题，打得我一脸懵逼。》
其中第一个关于线程池的场景，经过读者提醒可能有问题，我又一次用尽浑身解数分析了一波，发现之前确实分析的不对。
这个案例真的是再一次深入的刷新了我对于线程池运行过程的认知。
而由于我之前写过太多关于线程池的文章，对于线程池的运行过程太过于熟悉，基本熟悉到了源码信手拈来的地步。
所以我再次分析的时候，一度曾怀疑这个问题现象可能是 JDK 的 BUG，在 JDK BUG 库里面翻了一圈也没有发现有人提到过这个问题，我甚至想要发起这个问题。
最后阴差阳错的，还是定位到了问题的原因是线程池使用方面的问题，而问题的原因，最终说起来，极其简单，一点就透。
这一篇文章，歪师傅再次带大家盘一下这个问题。
问题再现
先给大家上代码：
这个问题最开始是一个读者提出来，发给我的一个 Demo，这个代码已经是我精简过的了。
这个代码运行起来会触发线程池的拒绝策略：
重点看一下我们的线程池定义：
private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(64, 64, 0, TimeUnit.MINUTES, new ArrayBlockingQueue<>(32));
该线程池核心大小数和最大线程数都是 64，队列长度为 32，也就是说这个线程池同时能容纳的任务数是 64+32=96。
但是从代码可以看出，由于有 countDownLatch 的存在，可以确认 for 循环一次一定只会放 34 个任务进来。
JDK 线程池的运行原理，大家应该都是背的滚瓜烂熟了：先启用核心线程，然后任务进队列，如果队列满了，再启用最大线程数。最大线程数也满了，就触发拒绝策略。
那么按照我个人的理解，因为我们的核心线程数就是 64 个，已经完全大于 34 个任务了，所以线程池完全可以吃下这 34 个任务。
完全没有理由触发拒绝策略啊？
所以，我在之前的文章中给出的结论是：
线程池里面的任务执行完成了，核心线程就一定会释放出来等着接受下一波循环的任务，但是不会立马释放出来。从释放到就绪之间，有一个时间差的存在，导致线程池核心线程数不够用，从而导致触发拒绝策略。
老实说，这个结论从纯理论的角度来说，是真的有可能的。所以我才写了一篇文章去论证它。
而且我还通过重写线程池的 afterExecute 方法，延长了“核心线程收尾的时间”来确保问题复现。
也确实复现了。
但是很遗憾，这个结论在这个案例中是错误的。
之前的文章说了：
“线程池两个工作”和“主线程继续往线程池里面扔任务的动作”之间，没有先后逻辑控制。
我的验证方式是通过延长了“核心线程收尾的时间”来确保问题复现。
但是这里有两个条件，所以其实还有一个验证方式：让“主线程继续往线程池里面扔任务的动作”足够的慢，让线程池有足够的事件去收尾，这样问题就一定不会出现。
然而我忽略了这个验证方式，一心只是想着复现问题。
所以，当读者给我这样的一个代码片段的时候，我直接就是一整个愣住了：
他在主线程中睡了 2s，目的是为了让“主线程继续往线程池里面扔任务的动作”足够的慢：
如果按照我之前的推测，那么线程池是完全足够时间让线程就绪的。
我自己也进行了验证，而且我甚至把时间拉长到 10s，这样也确实是会触发拒绝策略：
看到这个运行结果的时候，我本能上是抗拒的，因为这一行代码的加入，运行结果和我预测的完全相反，相当于直接推翻了我前面的结论。
但是歪师傅写文章这么多年了，还是见过一些大场面的。
于是迅速开始思考原因。
最开始我怀疑这里面的 sleep 动作有问题，于是我直接改成了这样，相当于模拟线程空跑一趟，什么动作都没有做：
但是还是会抛出异常。
然后我又开始怀疑 CountDownLatch，于是我直接去掉了相关的代码，整个代码变成了这样：
public class MyTest {
private static final ThreadPoolExecutor threadPoolExecutor =
new ThreadPoolExecutor(64, 64,
0, TimeUnit.MINUTES,
new ArrayBlockingQueue<>(32));
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 100; i++) {
Thread.sleep(100);
for (int j = 0; j < 34; j++) {
threadPoolExecutor.execute(() -> {
int a = 0;
});
}
System.out.println("===============> 详情任务 - 任务处理完成");
}
System.out.println("都执行完成了");
}
}
这个代码可以说已经非常简单了，除了线程池之外，没有其他的任何干扰项了。
但是，你直接粘过去跑，你会发现，还是会抛出异常：
核心线程数64，队列长度 32，每次往线程池里面扔 34 个任务，对应的任务完全没有任何耗时操作。
这样居然会触发线程池的拒绝策略？
又想起了几年前写文章时由于 idea “bug”遇到的诡异问题，甚至怀疑起了是“质子作祟”。
不知道你看到这里的时候有没有看出什么破绽，或者说新的思路。
反正我对着这份代码盯了一整天，调试了无数次，线程池的问题是真的难以调试，而且是在线程数比较多，没有排查思路的情况下，所以基本上没有什么进展。
峰回路转
事情的转机出现在我实在没有思路，然后开始重新复盘整个问题的时候。
再次翻看和提出这个问题的读者的聊天记录，这句话引起了我的注意：
解决问题的办法就是提高队列的容量。
我也不知道为什么，反正也没有思路，逮着个方向就顺便看看吧。
于是我直接把队列的长度从 32 提升到了 320：
程序立马就正常了：
32 不行，320 就行。
那么会不会存在一个临界值 x，当队列的长度小于 x 的时候，就会出问题，大于等于 x 的时候就一切正常呢？
按照这个思路，我用二分法，很快就定位到了这个 x= 34。
等于 34 啊，朋友，当时我都快兴奋的跳起来了。
34 和我们 for 循环一次往线程池里面扔的任务数是一样的，这里面一定是有内在联系的，虽然我现在还不知道是什么，但是至少也有一条线索了。
然后我又在队列的长度为 33 和 34 之间反复运行了很多次，确认在我的机器上运行， 33 的时候问题会必现，34 的时候程序就能正常完成。
基于这个现象，我得出了一个结论：队列长度小于 for 循环中一次放进来的任务数的时候，就会触发这个现象。
于是我一步步的多次调整参数，最终把参数修改为了这样：
线程池核心线程数还是 64，但是把队列长度修改为一，for 循环一次放两个任务进来。目的是最小程度的减少干扰项，然后神奇的事情就出现。
我现在把这个线程池定义单独拎出来：
来，你说，站在你的认知里面，隔 100ms 往这个线程池中扔两个任务进来。
会触发线程池的拒绝策略吗？
至少在我的认知里面是不可能的。
但是，它真的触发了：
而当我把核心线程数设置为 63，最大线程数保持为 64。或者核心线程数保持为 64，最大线程数修改为 65 时，其他代码都不动，程序均能正常运行。
匪夷所思，太匪夷所思了。
看到这个现象的时候，我直接开始怀疑是 JDK 的 BUG，当核心线程数和最大线程数一致的时候可能会触发，于是我用各种姿势搜了一圈，然而并没有什么收获。
同时我发现，当我保持核心线程数和最大线程数个数一致时，不管这个“个数”是 1 还是 100，都会触发拒绝策略。
虽然不知道原因，但是经过我对各种参数进行的调整，目前我有两个线索，只有当这两个线索同时满足的时候，就会触发拒绝策略：
队列长度小于 for 循环中一次放进来的任务数。 核心线程数和最大线程数个数一致。
虽然还是不知道具体的原因，但是我可以基于上面这两个线索，把参数的值取小一点，把 Demo 再简化一下，变成这样：
核心线程数等于最大线程数，都是 2，队列长度为 1，按理说这个队列最大可以容纳 3 个任务运行，但是一次性扔 2 个任务进去，会触发拒绝策略。
为什么？
我不知道，但是现在我有一个问题必现的 Demo，而且线程池里面的线程并不多，调试起来会轻松很多。
调试一波
首先我还是怀疑线程池里面的线程在下一次任务到来之前，没有进入到就绪状态。
也就是对应到 getTask 的这个部分：
java.util.concurrent.ThreadPoolExecutor#getTask
如果线程能运行到标号为 ③ 的地方，那么说明一定是就绪了，可以从队列中获取任务。
标号为 ① 的地方又是一个死循环的写法。会不会是在标号为 ② 的这一坨代码里面，有什么问题呢？
怎么验证呢？多线程场景下用 debug 还是很难定位到问题的。
我们可以用一种古老但有效的方法来进行验证：打足够多的日志。
只要我在标号为 ② 的地方，加入足够多的日志，就能帮助我分析代码到底是怎么运行的。
那么问题就来了：这个是 JDK 的源码，我怎么去加日志呢？
在我之前的这篇文章中提到过：《这篇文章关于一个源码调试方法，短小精悍，简单粗暴，但足够好用。》
把源码拷贝一份出来，原模原样的放一份到自己的项目中即可。
就像是这样：
为了区分，我把类粘过来之后，仅仅是修改了一个名字。但是你会发现有些报错的地方.
比如这里有个类型不匹配：
一看，是执行拒绝策略的方法。
不影响我们主要流程，直接参考默认的拒绝策略，抛出异常就行了：
然后就是这些拒绝策略也在报错，直接全部删除就完事了：
最后，你把程序里面的线程池换成你自己的，搞定：
现在，你就可以在 MyThreadPoolExecutor 随便加代码了：
通过控制台可以看到这个地方并没有在循环中多次循环，两个线程直接都运行到了“开始从队列中获取任务”的地方：
也就是都运行到了这个方法：
java.util.concurrent.ArrayBlockingQueue#take
这个方法很关键，指出我前一篇文章有问题的读者，也提到了这个方法：
我也想在这个 take 方法里面加点日志观察一下，同理我也把代码原模原样的粘一份出来，作为我的 MyArrayBlockingQueue，并替换线程池里面的队列：
因为可以确定线程是直接运行到 take 方法了，所以为了减少日志输出干扰，之前加的输出语句全部清除。
然后在 take 里面加这样的输出语句：
take 是消费者，对应的生产者在这个地方：
com.example.tomcatdemo.MyThreadPoolExecutor#execute
同理，我们在生产者这里加几行输出：
最终程序运行起来可以看到这样的日志输出：
线程池里面两个线程在等着队列里面来任务。
然后主线程在往队列里面提交任务。
相当于两个消费者，一个生产者。生产者生产一个，消费者立马就消费了。
这样就不会有任何毛病。
但是，还能看到这样的日志输出：
虽然两个消费者都就绪了，但是主线程往队列里面放了任务之后，任务并没有被及时消费，导致主线程放下一个任务的时候，队列满了。
对于线程池来说，队列满了意味着需要使用最大线程数了。
而在我们的案例里面，最大线程数等于核心线程数。所以没有线程拿来新增了，addWorker(command, false) 方法就会返回 false，所以触发了拒绝策略：
好，现在我再拿着 Demo 给你捋一下啊：
首先线程池的运行逻辑是：先启用核心线程，然后任务进队列，如果队列满了，再启用最大线程数。最大线程数也满了，就触发拒绝策略。
所以，当外层的第一次 for 循环的时候，提交的两个任务会直接启用最大线程数，和队列没有任何关系。
第二次 for 循环开始之后，提交的任务是先进队列，然后线程从队列里面取数据消费。
如果队列的长度只有 1，但是 for 循环一次要提交两个任务的时候，能否放成功，取决于核心线程从队列中拿（take）任务的动作，和主线程往队列里面放(offer)任务的动作，这两个动作之间的先后顺序。
如果核心线程先从队列中拿到任务，那么队列又有空间了，主线程可以继续往队列里面放任务，程序一切正常。
如果主线程往队列里面放任务的动作很快，放完第一个后，还没被消费，立马就开始放第二个，那么队列满了，即使我们知道，核心线程其实是在空闲状态，但是按照线程池的逻辑，会去开启最大线程数，发现最大线程数也没有了，所以触发了拒绝策略。
这个时候，你再回去看我们的“两个线索”的时候，你就明白过来是怎么回事了：
队列长度小于 for 循环中一次放进来的任务数。 核心线程数和最大线程数个数一致。
背后的逻辑，就这么简单，可以说是一点就透。
你看到这里，可能只花了五分钟时间。
但是当我定位到这个原因的时候，距离读者提出问题，已经过去了差不多三天时间，这期间，我走了很多弯路。
你看到的，是众多弯路中，唯一正确的一条路线。
而这一切的原因都在于我先入为主的认为，核心线程数大于提交的任务数，所以任务一定能找到对应的线程来进行处理，疏忽了任务是要先进队列的。
验证一波
我们还是简单验证一把。
在我们的场景下，队列长度为 1，每次放两个任务进来。
既然现在的核心问题在于 offer 和 take 这两个动作的先后顺序上。
如果核心线程的 take 动作，先于主线程第二次 offer 的动作，那么队列有空间，就不会触发拒绝策略。
为了验证这一点，我们需要在 offer 里面加点睡眠时间，拖慢它的处理速度：
也就是这样，在 offer 方法里面，往队列里面放任务的时候，睡一下：
按照我们前面的推理，这样理论上可以达到主线程 offer 一个进去，核心线程就 take 一个出去的效果，程序一定就会正常运行结束。
对不对？
对个头，不对啊！
你运行起来还是会抛出异常：
为什么，是我们又分析错了吗？
分析没错，只是临门一脚的时候，睡的地方不对。
你来看看这是一个什么宝贝：
offer 和 take 方法都要拿到锁之后才能进行入队、出队的动作。
所以睡一秒的动作，应该发在释放锁之后，否则主线程抱着着锁睡，核心线程只有干着急了：
这样，程序一定能正常运行结束。
同时，吸取了前一篇文章的教训，另外一个方向我也需要验证一下：
在 take 释放锁之后也睡一秒，模拟 take 操作慢，offer 塞满队列的情况。
这个情况，按照我们前面的分析，一定就会抛出异常：
至此，问题得到解决。
通过这次问题排除，也让我对于线程池参数的设置有了新的认知。
尽量不要把线程池的核心线程数和最大线程数设置的一样，把阻塞队列的长度设置得大一些，至少保证阻塞队列本身的长度大于一次提交进来的任务数，而不要做出线程数加上队列长度才勉强容纳单批次任务数，这么极端的长度参数。
另外，我也突然想到了线程池的 newFixedThreadPool 方法，不就是核心线程数等于最大线程数吗，它怎么没有问题呢？
看一下源码：
人家的队列用的是无参的 LinkedBlockingQueue，队列长度是 Integer.MAX_VALUE，当然不会有问题了。
另外，线程池里面还有这样的一个方法 newCachedThreadPool：
把核心线程数设置为 0，最大线程数放的无线大，超过 60s 空闲则回收线程，通过这个方式防止线程膨胀。
但是我的关注点其实在于它的队列，用的是 SynchronousQueue。
这个队列很有意思，它的工作过程是放一个进去之后，必须要拿走，才能放下一个。你可以理解它是一个通道，不存储任何元素，只是负责传递数据，它的队列长度是 0。
所以回到我们的场景中，如果我们的队列用的是它：
也不会触发到拒绝策略，程序也能正常运行结束。
现在我们知道的问题的原因，站在纯技术的角度，我们有非常多的方法来规避这个问题。但是具体怎么使用，还是得结合业务场景来看。
回顾
左边是最开始的代码，右边是最后定位问题的代码：
从左边到右边，我写了两篇文章，付出了很多的时间，经过了无数次的调试，一直在思维定时里面没有走出来，所以走了很多的弯路。
其实回顾整个问题的原因，一句话就能说清楚：
一次性提交的任务数量大于队列长度就有可能会触发。因为线程池核心线程都启动之后，任务提交都是先进队列。当你把最大线程数设置等于核心线程数时，根本就没有最大线程数可以用，所以会触发拒绝策略。当你把最大线程数设置大于核心线程数时，在最大线程数用完了的情况下，会触发拒绝策略。
但是，朋友，其实原因一点都不重要，当然定位到原因的时候我其实挺开心的。
我开心并不是因为找到了问题的原因，而是我觉得我在这个过程中付出的时间和无数次的调试，包括在这个过程中走过的所有弯路都是有意义的。
我写这篇文章是因为有读者读了我前一篇文章，发现有问题，告诉了我，让我有机会知道自己分析的有问题。
我写下这篇文章来记录找到问题的过程并分享出去，告诉大家我前一篇文章写的不对。
找问题的过程、方式和思考比最终的结论重要的多。这是一个相互学习，共同进步的过程，这比找到问题的原因，让我觉得更加有意义。
解决问题不厉害，因为当一个问题提出来的时候，它就已经被解决了。厉害的是带着怀疑的态度去看文章，结合自己的思考，然后提出问题。
带着质疑的眼光看代码，带着求真的态度去探索，与君共勉之。
·············· END ··············
推荐👍：Spring解决泛型擦除的思路不错，现在它是我的了。
你好呀，我是歪歪。我没进过一线大厂，没创过业，也没写过书，更不是技术专家，所以也没有什么亮眼的title。
当年高考，随缘调剂到了某二本院校计算机专业。纯属误打误撞，进入程序员的行列，之后开始了运气爆棚的程序员之路。
说起程序员之路还是有点意思，可以点击蓝字，查看我的程序员之路。