你也被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); 复制代码

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

入任务队列耗时？

线程池的任务队列是一个同步队列。因此入队列操做是同步的。

经常使用的几个同步队列：

1. LinkedBlockingQueue

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

2. ArrayBlockingQueue

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

3. SynchronousQueue

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

4. DelayQueue

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

因此使用特殊的同步队列仍是有可能致使execute方法阻塞一秒多的，好比SynchronousQueue。若是配合一个特殊的“拒绝策略”，是有可能形成这个现象的，咱们将在下面给出例子。

拒绝策略？

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

1. ThreadPoolExecutor.AbortPolicy：默认拒绝处理策略，丢弃任务并抛出异常。
2. ThreadPoolExecutor.DiscardPolicy：丢弃新来的任务，可是不抛出异常。
3. ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列头部（最旧的）的任务，而后从新尝试执行程序（若是再次失败，重复此过程）。
4. 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();  // 下面这段代码，第三行会输出1001  System.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接口。

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

关于做者

我是Yasin，一个有颜有料又有趣的程序员。

微信公众号：编了个程

我的网站：https://yasinshaw.com

关注个人公众号，和我一块儿成长~

公众号

本文使用 mdnice 排版