摘要：结合之前的线程快照，我发现这个消费线程也是处于状态，和后面的业务线程池一模一样。本地模拟本地也是创建了一个单线程的线程池，分别执行了两个任务。发现当任务中抛出一个没有捕获的异常时，线程池中的线程就会处于状态，同时所有的堆栈都和生产相符。
背景
事情（事故）是这样的，突然收到报警，线上某个应用里业务逻辑没有执行，导致的结果是数据库里的某些数据没有更新。
虽然是前人写的代码，但作为 Bug maker&killer 只能咬着牙上了。
因为之前没有接触过出问题这块的逻辑，所以简单理了下如图：
有一个生产线程一直源源不断的往队列写数据。
消费线程也一直不停的取出数据后写入后续的业务线程池。
业务线程池里的线程会对每个任务进行入库操作。
整个过程还是比较清晰的，就是一个典型的生产者消费者模型。
尝试定位接下来便是尝试定位这个问题，首先例行检查了以下几项：
是否内存有内存溢出？
应用 GC 是否有异常？
通过日志以及监控发现以上两项都是正常的。
紧接着便 dump 了线程快照查看业务线程池中的线程都在干啥。
结果发现所有业务线程池都处于 waiting 状态，队列也是空的。
同时生产者使用的队列却已经满了，没有任何消费迹象。
结合上面的流程图不难发现应该是消费队列的 Consumer 出问题了，导致上游的队列不能消费，下有的业务线程池没事可做。
review 代码于是查看了消费代码的业务逻辑，同时也发现消费线程是一个单线程。
结合之前的线程快照，我发现这个消费线程也是处于 waiting 状态，和后面的业务线程池一模一样。
他做的事情基本上就是对消息解析，之后丢到后面的业务线程池中，没有发现什么特别的地方。
但是由于里面的分支特别多（switch case），看着有点头疼；所以我与写这个业务代码的同学沟通后他告诉我确实也只是入口处解析了一下数据，后续所有的业务逻辑都是丢到线程池中处理的，于是我便带着这个前提去排查了（埋下了伏笔）。
因为这里消费的队列其实是一个 disruptor 队列；它和我们常用的 BlockQueue 不太一样，不是由开发者自定义一个消费逻辑进行处理的；而是在初始化队列时直接丢一个线程池进去，它会在内部使用这个线程池进行消费，同时回调一个方法，在这个方法里我们写自己的消费逻辑。
所以对于开发者而言，这个消费逻辑其实是一个黑盒。
于是在我反复 review 了消费代码中的数据解析逻辑发现不太可能出现问题后，便开始疯狂怀疑是不是 disruptor 自身的问题导致这个消费线程罢工了。
再翻了一阵 disruptor 的源码后依旧没发现什么问题后我咨询对 disruptor 较熟的@咖啡拿铁，在他的帮助下在本地模拟出来和生产一样的情况。
本地模拟本地也是创建了一个单线程的线程池，分别执行了两个任务。
第一个任务没啥好说的，就是简单的打印。
第二个任务会对一个数进行累加，加到 10 之后就抛出一个未捕获的异常。
接着我们来运行一下。
发现当任务中抛出一个没有捕获的异常时，线程池中的线程就会处于 waiting 状态，同时所有的堆栈都和生产相符。
细心的朋友会发现正常运行的线程名称和异常后处于 waiting 状态的线程名称是不一样的，这个后续分析。解决问题
当加入异常捕获后又如何呢？
程序肯定会正常运行。
同时会发现所有的任务都是由一个线程完成的。
虽说就是加了一行代码，但我们还是要搞清楚这里面的门门道道。
源码分析于是只有直接 debug 线程池的源码最快了；
通过刚才的异常堆栈我们进入到 ThreadPoolExecutor.java:1142 处。
发现线程池已经帮我们做了异常捕获，但依然会往上抛。
在 finally 块中会执行 processWorkerExit(w, completedAbruptly) 方法。
看过之前《如何优雅的使用和理解线程池》的朋友应该还会有印象。
线程池中的任务都会被包装为一个内部 Worker 对象执行。
processWorkerExit 可以简单的理解为是把当前运行的线程销毁（workers.remove(w)）、同时新增（addWorker()）一个 Worker 对象接着处理；
就像是哪个零件坏掉后重新换了一个新的接着工作，但是旧零件负责的任务就没有了。
接下来看看 addWorker() 做了什么事情：
只看这次比较关心的部分；添加成功后会直接执行他的 start() 的方法。
由于 Worker 实现了 Runnable 接口，所以本质上就是调用了 runWorker() 方法。
在 runWorker() 其实就是上文 ThreadPoolExecutor 抛出异常时的那个方法。
它会从队列里一直不停的获取待执行的任务，也就是 getTask()；在 getTask 也能看出它会一直从内置的队列取出任务。
而一旦队列是空的，它就会 waiting 在 workQueue.take()，也就是我们从堆栈中发现的 1067 行代码。
线程名字的变化上文还提到了异常后的线程名称发生了改变，其实在 addWorker() 方法中可以看到 new Worker()时就会重新命名线程的名称，默认就是把后缀的计数+1。
这样一切都能解释得通了，真相只有一个：
在单个线程的线程池中一但抛出了未被捕获的异常时，线程池会回收当前的线程并创建一个新的 Worker；总结
它也会一直不断的从队列里获取任务来执行，但由于这是一个消费线程，根本没有生产者往里边丢任务，所以它会一直 waiting 在从队列里获取任务处，所以也就造成了线上的队列没有消费，业务线程池没有执行的问题。
所以之后线上的那个问题加上异常捕获之后也变得正常了，但我还是有点纳闷的是：
既然后续所有的任务都是在线程池中执行的，也就是纯异步了，那即便是出现异常也不会抛到消费线程中啊。
这不是把我之前储备的知识点推翻了嘛？不信邪！之后我让运维给了加上异常捕获后的线上错误日志。
结果发现在上文提到的众多 switch case 中，最后一个竟然是直接操作的数据库，导致一个非空字段报错了
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/73681.html
摘要：第二还是大家对线程池的理解不够深刻，比如今天要探讨的内容。我认为线程池它就是一个调度任务的工具。而在线程池这个场景中却恰好就是要利用它只是一个普通方法调用。 showImg(https://segmentfault.com/img/remote/1460000018653817); 背景 上周分享了一篇《一个线程罢工的诡异事件》，最近也在公司内部分享了这个案例。 无独有偶，在内部分享的...
摘要：前言前段时间写过一篇线程池没你想的那么简单，和大家一起撸了一个基本的线程池，具备线程池基本调度功能。线程池自动扩容缩容。回调以上就是线程池的构造函数以及接口的定义。所以我们在使用线程池时，其中的任务一定要做好异常处理。线程异常捕获的重要性。 showImg(https://segmentfault.com/img/remote/1460000019403163?w=1904&h=108...
摘要：另载于是个很爽的东西，线程安全，能当全局变量来用别。第一家公司，使用框架老技术，现代人可以理解为类似，对每个请求都套上，进入时把写入，返回或抛注意时清理。第二家公司，某次引入一个设计，也用了来传递上下文信息，有的地方没能清掉。 另载于 http://www.qingjingjie.com/blogs/12 ThreadLocal是个很爽的东西，线程安全，能当全局变量来用(别！)。 上一...
摘要：倘若该回答是正确的，则立即有如下推论在处理信号的过程中，字节码具有原子性。因此，除了在两个字节码之间，应该还有其他时机唤起了。行的是信号处理函数的最外层包装，由系统调用或注册至内核，并在信号发生时被内核回调，是异常控制流的入口。 写在前面 前几天工作时遇到了一个匪夷所思的问题。经过几次尝试后问题得以解决，但问题产生的原因却仍令人费解。查找 SO 无果，我决定翻看 Python 的源码。...
阅读 2472·2021-10-19 11:45
阅读 2403·2021-09-30 09:56
阅读 1396·2021-09-30 09:47
阅读 579·2019-08-30 15:53
阅读 1817·2019-08-30 15:44
阅读 563·2019-08-30 12:52
阅读 1064·2019-08-30 11:16
阅读 1588·2019-08-29 16:36
