在我们进行代码开发时，我也见过很多全局注册一个自定义线程池（也有可能不是自定义的，直接使用更不推荐Executors 创建的线程池），也许是业务量不高、也许是其他原因，反正全局可这一个线程池使劲造。

先给大家看一段代码，也欢迎你在评论区留下你的看法！

一、看个代码

• 业务逻辑代码

• 

• 自定义线程池 BizThreadPool 代码如下

• 

通过上方的代码示例，如果你还没有看出问题，那你可以停留几秒思考一下。

自定义线程池创建，使用的这个队列，嗯......，大家工作中一定不要这么用，此处只是为了做演示使用。

如果你已经看出来了问题所在，也希望你能继续看下去，验证一下咱们是不是想的相同。

二、有啥问题

经过短暂几秒钟的思考之后，决定还是运行一下 Demo 看看现象。

封装一个 controller 直接启动 Springboot 程序，Java 启动。

启动成功之后调用 GET http://localhost:8080/test/test，输出结果如下。

按照我们的预期，日志中应该也要输出子任务才对啊，怎么创建的子任务没有输出呢，看现象应该是没有执行。

那我们先执行一下 jstack 命令看一下线程相关的信息，输出信息中其中一段如下所示。

通过上面的堆栈信息可以看出，主线程在将父任务执行完成之后，开启了一个CountDownLatch并等待3个子任务执行完成。

问题就在这，一直等待，一直等不到结果，所以就是我们刚开始看到的结果，只有父任务执行了，子任务并没有执行。

一次调用没有响应，多次调用之后，达到服务器资源瓶颈时系统就该发生崩溃了。

那么子任务为何没有执行到呢？

三、小试牛刀

首先我们从头开始捋一下，先看下线程池的配置。

我们在创建自定义线程池时，核心线程与最大线程都设置的1，那我们直接修改最大线程数量，让线程池有线程可以执行子任务不就行了吗？

对于生产中，核心线程与最大线程一般也不会设置为1，但是哪怕你设置为10、100、1000，极端情况下也会出现本文后面将要讲述的问题。

说干就干，创建自定义线程池的代码变为了如下形式。

非常自信的你重启程序，然后调用接口，最终傻眼了，怎么没变化？

如果你修改完最大线程数就去重启程序的话，说明线程池的工作原理你已经忘了！

好吧原谅你了，这次不准再忘了，下面跟我一起来看看这究竟是什么原因。

四、线程池工作流程

这里放一下线程池的工作流程。

面试官：线程池核心线程设置为0时任务执行流程怎么样的

知道了线程池的工作流程之后，在上述代码中，哪怕增加了最大线程池的数量，最终子任务也并不会执行到，我们可以打印一下当前线程池的状态进行辅助观察。（上述代码的printThreadPoolStatus()方法会进行线程池当前状态的打印）

调用一下GET http://localhost:8080/test/info方法查看线程池当前的状态。

可以看到队列中存在3个任务在排队，等待线程池分配线程执行任务。这也就是修改了最大线程池数量未生效的原因，因为还有一个无界队列。

当然如果任务一直增加，队列中任务数量越来越多，达到服务器的瓶颈，就会发生OOM了。（阿里开发规范中不推荐使用无界队列的原因）

五、修改核心线程数量

那我们直接修改核心线程数量吧，核心线程超过任务数量？

回答：不行。

对于我们上面的例子来说，增加核心线程数量，拥有可以执行子任务的线程，确实可以解决当下场景。

但是当并发量上来之后，或者说线程池的线程都被父线程所占用时，依旧会发现子任务无法获得线程执行。

此处我们修改核心线程为10执行看一下输出结果。

通过修改核心线程数量，解决了子任务在队列中堆积的问题。

所以通过上述代码，大家应该知道死锁是怎么发生的了吧，这里我总结一下。

六、小结

• 当核心线程为1，最大线程为1，使用无界队列。

  父任务在线程中等待子任务完成的通知，子任务在线程池的任务队列中等待线程池调度线程资源。

• 

• 当核心线程为1，最大线程为n，使用无界队列。

  最大线程设置n与设置1没有区别，除非使用的队列不同，只要是使用的无界队列，当资源耗尽之时，就是服务崩溃的时候。

  此时后面新的父任务到来时，也只会在任务队列中继续堆积。

• 

• 当核心线程为n，最大线程为n，使用无界队列。

  核心线程设置为n，意味着父线程大概率是可以执行的，创建的子任务在任务队列中排队执行。

• 

• 当并发量上来，或者核心线程都被父任务所占据之后，线程池调用就变成了如下场景，所有的任务都被堆积在任务队列当中

• 

• 核心线程全是父任务，后面创建的任务也都在任务队列堆积，最终达到服务器瓶颈系统OOM。

七、最终解决方案

通过上述代码示例，死锁的根本原因在于，父任务会创建多个子任务，并等待子任务执行结束，而父子任务都是使用的同一个线程池，当线程池中执行线程都是父任务时，所有的子任务又都在任务队列中等待执行，所以这样就会发生死锁。

核心线程永远不会释放，从而造成任务队列不断堆积，直到OOM。

所以解决方案就是，隔离线程池。

不同的业务使用不同的线程池，使用一个新的线程池处理子任务，这样就可以避免死锁的发生了。

修改之后的代码如下。

通过查看日志输出可以发现，线程池隔离之后，哪怕核心线程设置为1，也是可以正常执行业务逻辑的，任务队列中也没有堆积任务。

八、总结

通过上面的 Demo 复现以及解决方案，在工作中优化建议如下。

1、禁止使用Executors创建自定义线程池。使用ThreadPoolExecutor创建线程池时，注意每个参数的含义，规避资源耗尽的风险。

2、线程池使用有界队列，避免使用无界队列。

3、对于父子任务的场景，可以使用线程池或者 MQ。使用有界队列之后，制定合理的拒绝策略，拒绝策略可以考虑 MQ 做重试。

4、不同业务使用不同的线程池，禁止父子任务使用相同的线程池。