image.png
大家好，我是 why，一个四川程序猿，成都好男人。
技术分享之前先简短的荒腔走板聊聊生活。让文章的温度更多一点点。
image
上面的图是我在一次跑步的过程中拍的。活动之前赛事方搞了个留言活动，收集每公里路牌的一个宣传语。我的留言有幸被选中了：
没人知道你在坚持什么，但你自己心里应该清楚。是在说跑马拉松，也是在说其他的事情。
我记得那天的太阳，骄阳似火，路上的树荫也非常的少。苦就苦在我还报的是超级马拉松（说是超级马拉松，其实就是一个全马 42 km加最后 3 km纯上坡的马拉松）到底有多晒，我给你看一下对比：
image
酷暑难耐，以至于 30 公里左右的地方我的心里出现了两个小人：
一个说：我好累啊，我跑不动了，我要退赛。
一个说：好呀好呀，我也好晒啊，退赛退赛。
我说：呸，看你们两个不争气的东西，让我带你去终点
于是在 36 公里的地方碰到了我提交的标语，非常开心，停下来拍了几张照片。给自己说：坚持不住的时候再坚持一下。最后的 3 公里上坡，抽筋了不知道多少次。远远看见终点拱门的时候我突然想到了在敦煌的时候悟出的一句话：自己给自己的辛苦，不是辛苦，是幸福。
好了，说回文章。
违背自觉的JDK线程池
先用 JDK 线程池来开个题。
image
问：这是一个自定义线程池，假设这个时候来了 100 个比较耗时的任务，请问有多少个线程在运行？
正确回答在之前的文章中回答了，这里不在赘述。
但是我面试的时候曾经遇到过很多对于 JDK 线程池不了解的朋友。
而这些人当中大多数都有一个通病，那就是遇到不太会的问题，那就去猜。
面试者遇到这个不会的题的时候，表面上微微一笑，实际上我都已经揣摩出他们的内心活动了：
MD，这题我没背过呀，但是刚刚听面试官说核心线程数是 10，最大线程数是 30。看题也知道答案不是 10 就是 30。选择题，百分之 50 的命中率，难道不赌一把？
等等，30 是最大线程数？最大？我感觉就是它了。
于是在电光火石一瞬间的思考后，和我对视起来，自信的说：
image.png
于是我也是微微一笑，告诉他：下去再了解一下吧，我们聊聊别的。
image
确实，如果完全不了解 JDK 线程池运行规则，按照直觉来说，我也会觉得应该是，不管是核心还是最大线程数，有任务来了应该先把线程池里面可用的线程用完了，然后再把任务提交到队列里面去排队。
可惜 JDK 的线程池，就是反直觉的。
那有符合我们直觉的线程池吗？
有的，你经常用的的 Tomcat ，它里面的线程池的运行过程就是先把最大线程数用完，然后再提交任务到队列里面去的。
我带你剖析一下。
Tomcat线程池
先打开 Tomcat 的 server.xml 看一下：
image
眼熟吧？哪一个学过 java web 的人没有配置过这个文件？哪一个配置过这个文件的人没有留意过 Executor 配置？
具体的可配置项可以查看官方文档：
http://tomcat.apache.org/tomcat-9.0-doc/config/executor.html
同时我找到一个可配置的参数的中文说明如下：
image
注意其中的第一个参数是 className，图片中少了个字母 c。
然后还有两个参数没有介绍，我补充一下：
- prestartminSpareThreads：boolean 类型，当服务器启动时，是否要创建出最小空闲线程（核心线程）数量的线程，默认值为 false 。
- threadRenewalDelay：long 类型，当我们配置了 ThreadLocalLeakPreventionListener 的时候，它会监听一个请求是否停止。当线程停止后，如果有需要，会进行重建，为了避免多个线程，该设置可以检测是否有 2 个线程同时被创建，如果是，则会按照该参数，延迟指定时间创建。如果拒绝，则线程不会被重建。默认为 1000 ms，设定为负值表示不更新。
我们主要关注 className 参数，如果不配置，默认实现是：
org.apache.catalina.core.StandardThreadExecutor
我们先解读一下这个方法（注意，本文中 Tomcat 源码版本号为：10.0.0-M4）：
org.apache.catalina.core.StandardThreadExecutor#startInternal
image
从 123 行到 130 行，就是构建 Tomcat 线程池的地方，很关键，我解读一下：
123行
taskqueue = new TaskQueue(maxQueueSize);
创建一个 TaskQueue 队列，这个队列是继承自 LinkedBlockingQueue 的：
image
该队列上的注释值得关注一下：
主要是说这是一个专门为线程池设计的一个任务队列。配合线程池使用的时候和普通队列有不一样的地方。同时传递了一个队列长度，默认为 Integer.MAX_VALUE：
image
124行
TaskThreadFactory tf = new TaskThreadFactory(namePrefix,daemon,getThreadPriority());
构建一个 ThreadFactory，其三个入参分为如下：
image
- namePrefix：名称前缀。可以指定，其默认是“tomcat-exec-”。
- daemon：是否以守护线程模式启动。默认是 true。
- priority：线程优先级。是一个 1 到 10 之前的数，默认是 5。
125行
executor = new ThreadPoolExecutor(getMinSpareThreads(), getMaxThreads(), maxIdleTime, TimeUnit.MILLISECONDS,taskqueue, tf);
构建线程池，其 6 个入参分别如下：
image
这个具体含义我就不解释了，和 JDK 线程池是一样的。
只是给大家看一下默认参数。
image
另外还需要十分注意的一点是，这里的 ThreadPoolExecuteor 是 Tomcat 的，不是 JDK 的，虽然名字一样。
image
看一下 Tomcat 的 ThreadPoolExecuteor注释，里面提到了两个点，一是已提交总数，二是拒绝策略。后面都会讲到。
126行
executor.setThreadRenewalDelay(threadRenewalDelay);
设置 threadRenewalDelay 参数。不是本文重点，可以先不关心。
127 - 129行
if (prestartminSpareThreads) {
executor.prestartAllCoreThreads();
}
设置是否预启动所有的核心线程池，这个参数在之前文章中也有讲到过。
prestartminSpareThreads 参数默认是 false。但是我觉得这个地方你设置为 true 也是多次一举。完全没有必要。
为什么呢？
因为在 125 行构建线程池的时候已经调用过这个方法了：
image
从源码可以看出，不管你调用哪一个线程池构造方法，都会去调用 prestartAllCoreThreads 方法。
所以，这算不算 Tomcat 的一个小 Bug 呢？快拿起你的键盘给它提 pr 吧。
130行
taskqueue.setParent(executor);
这行代码非常关键。没有这行代码，Tomcat 的线程池则会表现的和 JDK 的线程池一样。
拿下面的程序举例：
image
自定义线程池最多可以容纳 150+300 个任务。
当 24 行注释的时候，Tomcat 线程池运行的过程和 JDK 线程池的运行过程一样，运行的线程数只会是核心程序数 5。
当 24 行取消注释的时候，Tomcat 线程池就会一直创建线程个数到 150 个，然后把剩下的任务提交到自定义的 TaskQueue 队列里面去。
我再提供一个复制粘贴直接运行版本，你分别运行一下，试一试，看看结果：
public class TomcatThreadPoolExecutorTest {
public static void main(String[] args) throws InterruptedException {
String namePrefix = "why不止技术-exec-";
boolean daemon = true;
TaskQueue taskqueue = new TaskQueue(300);
TaskThreadFactory tf = new TaskThreadFactory(namePrefix, daemon, Thread.NORM_PRIORITY);
ThreadPoolExecutor executor = new ThreadPoolExecutor(5,
150, 60000, TimeUnit.MILLISECONDS, taskqueue, tf);
//taskqueue.setParent(executor);
for (int i = 0; i < 300; i++) {
try {
executor.execute(() -> {
logStatus(executor, "创建任务");
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
} catch (Exception e) {
e.printStackTrace();
}
}
Thread.currentThread().join();
}
private static void logStatus(ThreadPoolExecutor executor, String name) {
TaskQueue queue = (TaskQueue) executor.getQueue();
System.out.println(Thread.currentThread().getName() + "-" + name + "-:" +
"核心线程数:" + executor.getCorePoolSize() +
"\t活动线程数:" + executor.getActiveCount() +
"\t最大线程数:" + executor.getMaximumPoolSize() +
"\t总任务数:" + executor.getTaskCount() +
"\t当前排队线程数:" + queue.size() +
"\t队列剩余大小:" + queue.remainingCapacity());
}
}
接着就去分析这行代码的用途，看看这一行代码，怎么就反转了 JDK 线程池的运行过程。
源码之下无秘密
如果你对 JDK 线程池的源码熟悉一点的话，你大概能猜到 Tomcat 肯定是在控制新建线程的地方做了手脚，也就是下面这个地方：
image
PS：需要说明一下的是，上面的截图是 JDK 线程池的 execute 方法。因为 Tomcat 线程池的提交也是复用的这个方法。但是 workQueue 不是同一个队列。
image.png
那你先把工作流程和各个参数都摸熟了，然后写个 Demo ，接着去疯狂的 Debug 吧。然后你总会找到这个地方的，而且你会发现，不难找。
好了，上面主要关注我圈起来的部分。
在截图的 1371 行，如果没有把任务成功放到队列里面（前提是线程池是运行状态），则会执行 1378 行的逻辑，而这个逻辑，就是创建非核心线程的逻辑。
所以，经过上面的推导之后，一切都清晰了，Tomcat 只需要在自定义队列的 offer 方法中做文章即可。
所以，我们重点关注一下该方法：
org.apache.tomcat.util.threads.TaskQueue#offer
image
为了更加直观的看出来其运行流畅，我在第 80 行打了个断点运行程序如下：
image
可以看到里面的几个参数，下面的讲解会用到这里面的参数：
image
第一个 if 判断
首先第一个 if，判断 parent 是否为空：
image
从断点运行参数截图可以看出，这里的 parent 就是 Tomcat 的 ThreadPoolExecutor 类。
当 parent 为 null 时，直接调用原始的 offer 方法。
所以，还记得我前面说的吗？
image
现在你知道为什么了吧？
源码，就是这个源码。道理，就是这么个道理。
所以，这里不为空，不满足条件，进入下一个 if 判断。
第二个 if 判断
image
首先，需要明确的是，能进入到第二个判断的时候，当前运行中的线程数肯定是大于等于核心线程数（因为已经在执行往队列里面放的逻辑了，说明核心线程数肯定是满了），小于最大线程数的。
其中 getPoolSize 方法是获取线程池中当前运行的线程数量：
image
所以，第二个 if 判断的是运行中的线程数是否等于最大线程数。如果等于，说明所有线程都在工作了，把任务扔到队列里面去。
从断点运行参数截图可以看到， 当前运行数为 5 ，最大线程数为 150。不满足条件，进入下一个 if 判断。
第三个 if 判断
image
首先我们看看 getSubmittedCount 获取的是个什么玩意：
image
getSubmittedCount 获取的是当前已经提交但是还未完成的任务的数量，其值是队列中的数量加上正在运行的任务的数量。
从断点运行参数截图可以看到，当前情况下该数据为 6。而 parent.getPoolSize() 为 5。
不满足条件，进入下一个 if 判断。
但是这个地方需要多说一句的是，如果当已经提交但是还未完成的任务的数量小于线程池中运行线程的数量时，Tomcat 的做法是把任务放到队列里面去，而不是立即执行。
其实这样想来也是很符合逻辑且简单的做法的。
反正有空闲的线程嘛，扔到队列里面去就被空闲的线程消费了。又何必立即执行呢？破坏流程不说，还需要额外实现。
出力不讨好。没必要。
第四个 if 判断
image
这个判断就很关键了。
如果当前运行中的线程数量小于最大线程数，返回 false。
注意哦，前面的几个 if 判断都是不满足条件就放入队列哦。而这里是不满足条件，就返回 false。
返回 false 意味着什么？
image
意味着要执行 1378 行代码，去创建线程了呀。
所以，整个流程图大概就是这样：
image
再聊聊拒绝策略
拒绝策略需要看这个方法：
org.apache.tomcat.util.threads.ThreadPoolExecutor#execute(java.lang.Runnable, long, java.util.concurrent.TimeUnit)
看一下该方法上的注释：
image
如果队列满了，则会等待指定时间后再次放入队列。
如果再次放入队列的时候还是满的，则抛出拒绝异常。
这个逻辑就类似于你去上厕所，发现坑位全都被人占着。这个时候你的身体告诉你，你括弧肌最多还能在忍一分钟。
于是，你掐着表在门口，深呼吸，闭眼冥想，等了一分钟。
运气好的，再去一看：哎，有个空的坑位了，赶紧占着。
运气不好，再去一看：哎，还是没有位置，怎么办呢？抛异常吧。具体怎么抛就不说了，自行想象。
image.png
所以我们看看这个地方,Tomcat 的代码是怎么实现的：
image
catch 部分首先判断队列是不是 Tomcat 的自定义队列。如果是，则进入这个 if 分支。
关键的逻辑就在这个 if 判断里面了。
可以看到 172 行：
if (!queue.force(command, timeout, unit))
调用了队列的 force 方法。我们知道 BlockingQueue 是没有 force 方法的。
所以这个force 是 Tomcat 自定义队列特有的方法：
public boolean force(Runnable o, long timeout, TimeUnit unit) throws InterruptedException {
if (parent == null || parent.isShutdown())
throw new RejectedExecutionException(sm.getString("taskQueue.notRunning"));
//forces the item onto the queue, to be used if the task is rejected
return super.offer(o,timeout,unit);
}
进去一看发现：害，也不过如此嘛。就是对原生 offer 方法的一层包装而已。
如果成功加入队列则万事大吉，啥事没有。
如果没有成功加入队列，则抛出异常，并维护 submittedCount 参数。
image
前面说过：submittedCount 参数 = 队列中的任务个数 + 正在运行的任务数。
所以，这里需要进行减一操作。
拒绝策略就说完了。
但是这个地方的源码是我带你找到的。如果你想自己找到应该怎么操作呢？
你想啊，你是想测试拒绝策略。那只要触发其拒绝策略就行了。
比如下面这样：
image
给一个只能容纳 450 个任务的线程池提交 500 个任务。
然后就会抛出这个异常：
image
就会找到 Tomcat 线程池的 174 行：
image
然后你打上一个断点，玩去吧。
那我们刚刚说的，可以在门口等一分钟再进坑是怎么回事呢？
我们把参数告诉线程池就可以了，比如下面这样：
image
然后再去运行，因为队列满了后，触发拒绝异常，然后等 3 秒再去提交任务。而我们提交的一个任务 2 秒就能被执行完。
所以，这个场景下，所有的任务都会被正常执行。
现在你知道为了把你给它的任务尽量快速、全部的执行完成，Tomcat有多努力了吗？
image
小彩蛋
在看 Tomcat 自定义队列的时候我发现了作者这样的注释：
image
这个地方作用是把 forcedRemainingCapacity 参数设置为 0。
这个参数是在什么时候设置的呢？
就是下面这个关闭方法的时候：
org.apache.tomcat.util.threads.ThreadPoolExecutor#contextStopping
image
可以看到，调用 setCorePoolSize 方法之前，作者直接把 forcedRemainingCapacity 参数设置为了 0。
注释上面写的原因是JDK ThreadPoolExecutor.setCorePoolSize 方法会去检查 remainingCapacity 是否为 0。
至于为什么会去做这样的检查，Tomcat 的作者两次表示：I don't see why。I did not understand why。
so，他 fake 了 condition。
image
总之就是他说他也不明白为什么JDK 线程池 setCorePoolSize 方法调小核心线程池的时候要的限制队列剩余长度为 0 ，反正这样写就对了。
别问，问就是规定。
于是我去看了 JDK 线程池的 setCorePoolSize 方法，发现这个限制是在 jdk 1.6 里有，1.6 之后的版本对线程池进行了大规模的重构，取消了这个限制：
image
那 Tomcat 直接设置为 0 会带来什么问题呢？
正常的逻辑是队列剩余大小 = 队列长度 - 队列里排队的任务数。
image
而当你对其线程池（队列长度为300）进行监控的时候正常情况应该是这样：
image
但是当你调用 contextStopping 方法后可能会出现这样的问题：
image
很明显不符合上面的算法了。
好了，如果你们以后需要对 Tomcat 的线程池进行监控，且 JDK 版本在 1.6版本以上。那你可以去掉这个限制，以免误报警。
好了，恭喜你，朋友。又学到了一个基本用不上的知识点，奇怪的知识又增加了一点点。
image.png
Dubbo 线程池
这里再扩展一个 Dubbo 的线程池实现。
image
org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutor
你可以看一下，思想还是这个思想：
image
但是 execute 方法有点不一样：
image
从代码上看，这里放入失败之后又立马调了一次 offer 方法，且没有等待时间。也就是说两次 offer 的间隔是非常的短的。
其实我不太明白为什么这样去写，可能是作者留着口子好扩展吧？
因为如果这样写，为什么不直接调用这个方法呢？
java.util.concurrent.LinkedBlockingQueue#offer(E)
也是作者是想在极短的时间能赌一下吧？谁知道呢？
然后可以发现该线程池在拒绝策略上也做了很大的文章：
image
可以看到日志打印的非常详尽，warn 级别：
image
dumpJStack 方法，看名字也知道它是要去 Dump 线程了，保留现场：
image
在这个方法里面，他用了 JDK 默认的线程池，去异常 Dump 线程。
等等，阿里开发规范不是说了不建议用默认线程池吗？
其实这个规范看你怎么去拿捏。在这个场景下，用自带的线程池就能满足需求了。
而且你看第二个红框：提交之后就执行了 shutdown 方法，上面还给了个贴心警告。
必须要 shutdown 线程池，不然会导致 OOM。
这就是细节呀，朋友们。魔鬼都在细节里！
这里为什么用的 shutdown 不是 shutdownNow ？他们的区别是什么？为什么不调用 shutdown 方法会 OOM？
知识点呀，朋友们，都是知识点啊！
image
好了，到这里本文的分享也到了尾声。
以后当面试官问你 JDK 线程池的运行流程的时候，你答完之后画风一转，再来一个：
其实我们也可以先把最大线程数用完，然后再让任务进入队列。通过自定义队列，重写其 offer 方法就可以实现。目前我知道的 Tomcat 和 Dubbo 都提供了这样策略的线程池。
轻描淡写之间又装了一个漂亮逼。让面试官能进入下一个知识点，让你能更多的展现自己。
image
来源于why不止技术 ，作者why技术
网友评论