資訊專欄INFORMATION COLUMN
摘要：結合之前的線程快照，我發現這個消費線程也是處于狀態，和后面的業務線程池一模一樣。本地模擬本地也是創建了一個單線程的線程池，分別執行了兩個任務。發現當任務中拋出一個沒有捕獲的異常時，線程池中的線程就會處于狀態，同時所有的堆棧都和生產相符。
背景
事情（事故）是這樣的，突然收到報警，線上某個應用里業務邏輯沒有執行，導致的結果是數據庫里的某些數據沒有更新。
雖然是前人寫的代碼，但作為 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 中，最后一個竟然是直接操作的數據庫，導致一個非空字段報錯了
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/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 的源碼。...
閱讀 2497·2021-10-19 11:45
閱讀 2489·2021-09-30 09:56
閱讀 1442·2021-09-30 09:47
閱讀 602·2019-08-30 15:53
閱讀 1841·2019-08-30 15:44
閱讀 590·2019-08-30 12:52
閱讀 1093·2019-08-30 11:16
閱讀 1617·2019-08-29 16:36
