事情（事故）是这样的，突然收到报警，线上某个应用里业务逻辑没有执行，导致的结果是数据库里的某些数据没有更新。

虽然是前人写的代码，但作为 `Bug maker&killer` 只能咬着牙上了。

因为之前没有接触过出问题这块的逻辑，所以简单理了下如图：

1. 有一个生产线程一直源源不断的往队列写数据。

2. 消费线程也一直不停的取出数据后写入后续的业务线程池。

3. 业务线程池里的线程会对每个任务进行入库操作。

整个过程还是比较清晰的，就是一个典型的生产者消费者模型。

接下来便是尝试定位这个问题，首先例行检查了以下几项：

- 是否内存有内存溢出？

- 应用 GC 是否有异常？

通过日志以及监控发现以上两项都是正常的。

紧接着便 dump 了线程快照查看业务线程池中的线程都在干啥。

结果发现所有业务线程池都处于 `waiting` 状态，队列也是空的。

同时生产者使用的队列却已经满了，没有任何消费迹象。

结合上面的流程图不难发现应该是消费队列的 `Consumer` 出问题了，导致上游的队列不能消费，下有的业务线程池没事可做。

于是查看了消费代码的业务逻辑，同时也发现消费线程是一个**单线程**。

结合之前的线程快照，我发现这个消费线程也是处于 waiting 状态，和后面的业务线程池一模一样。

他做的事情基本上就是对消息解析，之后丢到后面的业务线程池中，没有发现什么特别的地方。

因为这里消费的队列其实是一个 `disruptor` 队列；它和我们常用的 `BlockQueue` 不太一样，不是由开发者自定义一个消费逻辑进行处理的；而是在初始化队列时直接丢一个线程池进去，它会在内部使用这个线程池进行消费，同时回调一个方法，在这个方法里我们写自己的消费逻辑。

所以对于开发者而言，这个消费逻辑其实是一个黑盒。

于是在我反复 `review` 了消费代码中的数据解析逻辑发现不太可能出现问题后，便开始疯狂怀疑是不是 `disruptor` 自身的问题导致这个消费线程罢工了。

再翻了一阵 `disruptor` 的源码后依旧没发现什么问题后我咨询对 `disruptor` 较熟的@咖啡拿铁，在他的帮助下在本地模拟出来和生产一样的情况。

本地也是创建了一个单线程的线程池，分别执行了两个任务。

- 第一个任务没啥好说的，就是简单的打印。

- 第二个任务会对一个数进行累加，加到 10 之后就抛出一个未捕获的异常。

接着我们来运行一下。

发现当任务中抛出一个没有捕获的异常时，线程池中的线程就会处于 `waiting` 状态，同时所有的堆栈都和生产相符。

当加入异常捕获后又如何呢？

程序肯定会正常运行。

虽说就是加了一行代码，但我们还是要搞清楚这里面的门门道道。

于是只有直接 `debug` 线程池的源码最快了；

通过刚才的异常堆栈我们进入到 `ThreadPoolExecutor.java:1142` 处。

- 发现线程池已经帮我们做了异常捕获，但依然会往上抛。

- 在 `finally` 块中会执行 `processWorkerExit(w, completedAbruptly)` 方法。

看过之前[《如何优雅的使用和理解线程池》](https://crossoverjie.top/2018/07/29/java-senior/ThreadPool/)的朋友应该还会有印象。

线程池中的任务都会被包装为一个内部 `Worker` 对象执行。

`processWorkerExit` 可以简单的理解为是把当前运行的线程销毁（`workers.remove(w)`）、同时新增（`addWorker()`）一个 `Worker` 对象接着处理；

接下来看看 `addWorker()` 做了什么事情：

只看这次比较关心的部分；添加成功后会直接执行他的 `start()` 的方法。

由于 `Worker` 实现了 `Runnable` 接口，所以本质上就是调用了 `runWorker()` 方法。

在 `runWorker()` 其实就是上文 `ThreadPoolExecutor` 抛出异常时的那个方法。

它会从队列里一直不停的获取待执行的任务，也就是 `getTask()`；在 `getTask` 也能看出它会一直从内置的队列取出任务。

而一旦队列是空的，它就会 `waiting` 在 `workQueue.take()`，也就是我们从堆栈中发现的 1067 行代码。

上文还提到了异常后的线程名称发生了改变，其实在 `addWorker()` 方法中可以看到 `new Worker()`时就会重新命名线程的名称，默认就是把后缀的计数+1。

这样一切都能解释得通了，真相只有一个：

所以之后线上的那个问题加上异常捕获之后也变得正常了，但我还是有点纳闷的是：

这不是把我之前储备的知识点推翻了嘛？不信邪！之后我让运维给了加上异常捕获后的线上错误日志。

结果发现在上文提到的众多 `switch case` 中，最后一个竟然是直接操作的数据库，导致一个非空字段报错了🤬！！

这事也给我个教训，还是得眼见为实啊。

虽然这个问题改动很小解决了，但复盘整个过程还是有许多需要改进的：

1. 消费队列的线程名称竟然和业务线程的前缀一样，导致我光找它就花了许多时间，命名必须得调整。

2. 开发规范，防御式编程大家需要养成习惯。

3. 未知的技术栈需要谨慎，比如 `disruptor`，之前的团队应该只是看了个高性能的介绍就直接使用，并没有深究其原理；导致出现问题后对它拿不准。

实例代码：

**你的点赞与分享是对我最大的支持**

上周分享了一篇[《一个线程罢工的诡异事件》](docs/jvm/thread-gone.md)，最近也在公司内部分享了这个案例。

无独有偶，在内部分享的时候也有小伙伴问了之前分享时所提出的一类问题：

这其实是一类共性问题，我认为主要还是两个原因：

- 我自己确实也没讲清楚，之前画的那张图还需要再完善，有些误导。

- 第二还是大家对线程池的理解不够深刻，比如今天要探讨的内容。

首先还是来复习下线程池的基本原理。

我认为线程池它就是一个**调度任务**的工具。

众所周知在初始化线程池会给定线程池的大小，假设现在我们有 1000 个线程任务需要运行，而线程池的大小为 10~20，在真正运行任务的过程中他肯定不会创建这1000个线程同时运行，而是充分利用线程池里这 10~20 个线程来调度这1000个任务。

而这里的 10~20 个线程最后会由线程池封装为 `ThreadPoolExecutor.Worker` 对象，而这个 `Worker` 是实现了 Runnable 接口的，所以他自己本身就是一个线程。

这里我们来做一个模拟，创建了一个核心线程、最大线程数、阻塞队列都为2的线程池。

这里假设线程池已经完成了预热，也就是线程池内部已经创建好了两个线程 `Worker`。

当我们往一个线程池丢一个任务会发生什么事呢？

- 第一步是生产者，也就是任务提供者他执行了一个 execute() 方法，本质上就是往这个内部队列里放了一个任务。

- 之前已经创建好了的 Worker 线程会执行一个 `while` 循环 ---> 不停的从这个`内部队列`里获取任务。(这一步是竞争的关系，都会抢着从队列里获取任务，由这个队列内部实现了线程安全。)

- 获取得到一个任务后，其实也就是拿到了一个 `Runnable` 对象(也就是 `execute(Runnable task)` 这里所提交的任务)，接着执行这个 `Runnable` 的 **run() 方法，而不是 start()**，这点需要注意后文分析原因。

结合源码来看：

从图中其实就对应了刚才提到的二三两步：

- `while` 循环，从 `getTask()` 方法中一直不停的获取任务。

- 拿到任务后，执行它的 run() 方法。

这样一个线程就调度完毕，然后再次进入循环从队列里取任务并不断的进行调度。

接下来回顾一下我们上一篇文章所提到的，导致一个线程没有运行的根本原因是：

结合之前的那张图来看：

这里大家问的最多的一个点是，为什么会没有是`根本没有生产者往里边丢任务`，图中不是明明画的有一个 `product` 嘛？

这里确实是有些不太清楚，再次强调一次：

**图中的 product 是往内部队列里写消息的生产者，并不是往这个 Consumer 所在的线程池中写任务的生产者。**

因为即便 `Consumer` 是一个单线程的线程池，它依然具有一个常规线程池所具备的所有条件：

- Worker 调度线程，也就是线程池运行的线程；虽然只有一个。

- 内部的阻塞队列；虽然长度只有1。

再次结合图来看：

所以之前提到的【没有生产者往里边丢任务】是指右图放大后的那一块，也就是内部队列并没有其他线程往里边丢任务执行 `execute()` 方法。

而一旦发生未捕获的异常后，`Worker1` 被回收，顺带的它所调度的线程 `task1`（这个task1 也就是在执行一个 while 循环消费左图中的那个队列） 也会被回收掉。

新创建的 `Worker2` 会取代 `Worker1` 继续执行 `while` 循环从内部队列里获取任务，但此时这个队列就一直会是空的，所以也就是处于 `Waiting` 状态。

问题搞清楚后来想想为什么线程池在调度的时候执行的是 `Runnable` 的 `run()` 方法，而不是 `start()` 方法呢？

我相信大部分没有看过源码的同学心中第一个印象就应该是执行的 `start()` 方法；

因为不管是学校老师，还是网上大牛讲的都是只有执行了` start()` 方法后操作系统才会给我们创建一个独立的线程来运行，而 `run()` 方法只是一个普通的方法调用。

而在线程池这个场景中却恰好就是要利用它**只是一个普通方法调用**。

回到我在文初中所提到的：我认为线程池它就是一个**调度任务**的工具。

假设这里是调用的 `Runnable` 的 `start` 方法，那会发生什么事情。

如果我们往一个核心、最大线程数为 2 的线程池里丢了 1000 个任务，**那么它会额外的创建 1000 个线程，同时每个任务都是异步执行的，一下子就执行完毕了**。

从而没法做到由这两个 `Worker` 线程来调度这 1000 个任务，而只有当做一个同步阻塞的 `run()` 方法调用时才能满足这个要求。

针对之前线上事故的总结上次已经写得差不多了，感兴趣的可以翻回去看看。

这次呢可能更多是我自己的总结，比如写一篇技术博客时如果大部分人对某一个知识点讨论的比较热烈时，那一定是作者要么讲错了，要么没讲清楚。

这点确实是要把自己作为一个读者的角度来看，不然很容易出现之前的一些误解。

在这之外呢，我觉得对于线程池把这两篇都看完同时也理解后对于大家理解线程池，利用线程池完成工作也是有很大好处的。

如果有在面试中加分的记得回来点赞、分享啊。

**你的点赞与分享是对我最大的支持**