你也被Spring的这个“线程池”坑过吗？

前两天一个晚上，正当我沉浸在敲代码的快乐中时，听到隔壁的同事传来一声不可置信的惊呼：线程池提交命令怎么可能会执行一秒多？

线程池提交方法执行一秒多？那不对啊，线程池提交应该是一个很快的操作，一般情况下不应该执行一秒多那么长的时间。

看了一下那段代码，好像也没什么问题，就是一个简单的提交任务的代码。

executor.execute( () -> {// 具体的任务代码// 这里有个for循环
});

虽然执行的Job里面有一个for循环，可能比较耗时，但是execute提交任务的时候，并不会去真正去执行Job，所以应该不是这个原因引起的。

分析

看到这个情况，我们首先想到的是线程池提交任务时候的一个处理过程：

线程池原理图

然后逐个分析一下有可能耗时一秒多的操作：

创建线程耗时？

根据上面的图，我们可以知道，如果核心线程数量设置过大，就可能会不断创建新的核心线程去执行任务。同理，如果核心线程池和任务队列都满了，会创建非核心线程去执行任务。

创建线程是比较耗时的，而且Java线程池在这里创建线程的时候还上了锁。

final ReentrantLock mainLock = this.mainLock;
mainLock.lock();

我们写个简单的程序，可以模拟出来线程池耗时的操作，下面这段代码创建2w个线程，在我的电脑里大概会耗时6k多毫秒。

long before = System.currentTimeMillis();
for (int i = 0; i < 20000; i++) {// doSomething里面睡眠一秒new Thread(() -> doSomething()).start();
}
long after = System.currentTimeMillis();
// 下面这行在我的电脑里输出6139
System.out.println(after - before);

但是看了一下我们的监控，线程数量一直比较健康，应该不是这个原因。再说那个地方新线程也不太可能达到这个量级。

入任务队列耗时？

线程池的任务队列是一个同步队列。所以入队列操作是同步的。

常用的几个同步队列：

LinkedBlockingQueue

链式阻塞队列，底层数据结构是链表，默认大小是Integer.MAX_VALUE，也可以指定大小。
ArrayBlockingQueue

数组阻塞队列，底层数据结构是数组，需要指定队列的大小。
SynchronousQueue

同步队列，内部容量为0，每个put操作必须等待一个take操作，反之亦然。
DelayQueue

延迟队列，该队列中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。

所以使用特殊的同步队列还是有可能导致execute方法阻塞一秒多的，比如SynchronousQueue。如果配合一个特殊的“拒绝策略”，是有可能造成这个现象的，我们将在下面给出例子。

拒绝策略？

线程数量达到最大线程数就会采用拒绝处理策略，四种拒绝处理的策略为：

ThreadPoolExecutor.AbortPolicy：默认拒绝处理策略，丢弃任务并抛出异常。
ThreadPoolExecutor.DiscardPolicy：丢弃新来的任务，但是不抛出异常。
ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列头部（最旧的）的任务，然后重新尝试执行程序（如果再次失败，重复此过程）。
ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务。

可以看到，前面三种拒绝处理策略都是会“丢弃”任务，而最后一种不会。最后一种拒绝策略配合上面的SynchronousQueue，就有可能造成我们遇到的情况。示例代码：

Executor executor = new ThreadPoolExecutor(2,2, 2, TimeUnit.MILLISECONDS,new SynchronousQueue<>(), new ThreadPoolExecutor.CallerRunsPolicy());
for (int i = 0; i < 3; i++) {long before = System.currentTimeMillis();executor.execute( () -> {// doSomething里面睡眠一秒doSomething();});long after = System.currentTimeMillis();// 下面这段代码，第三行会输出1001System.out.println(after - before);
}

SimpleAsyncTaskExecutor

所以我们遇到的问题会是上面的种种原因导致的吗？带着这些猜测，我们去找到了定义executor的代码。

SimpleAsyncTaskExecutor executor = new SimpleAsyncTaskExecutor();
executor.setConcurrencyLimit(20);

设置最大并发数量是20好像没什么问题，等等，这个SimpleAsyncTaskExecutor是个什么鬼？

好像是Spring提供的一个线程池吧……（声音逐渐不自信）

em…看了一下包的定义，org.springframework.core.task，确实是Spring提供的。至于是不是线程池，先看看类图：

实现的是Executor接口，但是继承树里为什么没有ThreadPoolExecutor？我们猜测可能是Spring自己实现了一个线程池？虽然应该没什么必要。

源码

带着疑问，我们继续看了一下这个类的源码。主要看execute方法，发现每次执行之前，都要先调用一个beforeAccess方法，这个方法里面有这样一段很奇怪的代码：

beforeAccess

while循环去检查，如果当前并发线程数量大于等于设置的最大值，就等待。

找到原因了，这应该就是罪魁祸首。可是为什么Spring要这么设计呢？

我们在SimpleAsyncTaskExecutor类的注释上面找到了作者的留言：

 * <p><b>NOTE: This implementation does not reuse threads!</b> Consider a* thread-pooling TaskExecutor implementation instead, in particular for* executing a large number of short-lived tasks.

大概意思就是：这个实现并不复用线程，如果你要复用线程请去使用线程池的实现。这个是用来执行很多耗时很短的任务的。

至此，真相大白。

反思

使用接口前先了解一下

造成这个问题的根本原因是，我们以为SimpleAsyncTaskExecutor是一个“线程池”，而其实它不是！！！

我们在使用开源项目的时候，往往直接就用了，不会去仔细看看它的源码，也可能没有考虑清楚它的应用环境。等到程序出问题了才发现，已经晚了。

所以使用接口之前最好先了解一下，至少要看看官方文档或者接口文档/注释。

哪怕是真的出问题了，看源码也不失为一种排查问题的方式，因为代码都是死的，它不会骗人。

代码规约

阿里有这么一个代码规约：不建议我们直接使用Executors类中的线程池，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学需要更加明确线程池的运行规则，规避资源耗尽的风险。

以前我还不太理解，心想使用Executors类可以提高可读性，JDK提供了这样的工具类，不用白不用。直到遇到这个问题，才明白这条规约的良苦用心。

如果我们使用规范的方式去使用线程池，而不是用一个所谓的Spring提供的“线程池”，就不会遇到这个问题了。

明确接口职责

再来想一想为什么同事会把它当成一个线程池？因为它的类名、方法名都太像一个线程池了。它实现了Executor接口的execute方法，才导致我们误以为它是一个线程池。

所以回归到Executor这个接口上来，它的职责究竟是什么？我们可以在JDK的execute方法上看到这个注释：

/**
* Executes the given command at some time in the future.  The command
* may execute in a new thread, in a pooled thread, or in the calling
* thread, at the discretion of the {@code Executor} implementation.
*/

大意就是，在将来某个时间执行传入的命令，这个命令可能会在一个新的线程里面执行，可能会在线程池里，也可能在调用这个方法的线程中，具体怎么执行是由实现类去决定的。

所以这才是Executor这个类的职责，它的职责并不是提供一个线程池的接口，而是提供一个“将来执行命令”的接口。

所以，真正能代表线程池意义的，是ThreadPoolExecutor类，而不是Executor接口。

在我们写代码的时候，也要定义清楚接口的职责哟。这样别人用你的接口或者阅读源码的时候，才不会疑惑。

有道无术，术可成；有术无道，止于术

欢迎大家关注Java之道公众号

好文章，我在看❤️