線程池遇到父子任務，有大坑，要注意！
你好呀，我是歪歪。
最近在使用線程池的時候踩了一個坑，給你分享一下。
在實際業務場景下，涉及到業務代碼和不同的微服務，導致問題有點難以定位，但是最終分析出原因之后，發現可以用一個很簡單的例子來演示。
所以歪師傅這次先用 Demo 說問題，再說場景，方便吸收。
Demo
老規矩，還是先上個代碼：
圖片
這個代碼的邏輯非常簡單，首先我們搞了一個線程池，然后起一個 for 循環往線程池里面仍了 5 個任務，這是核心邏輯。
對于這幾個任務，我們的這個自定義線程池處理起來，不能說得心應手吧，至少也是手拿把掐。
其他的 StopWatch 是為了統計運行時間用的。至于 CountDownLatch，你可以理解為在業務流程中，需要這五個任務都執行完成之后才能往下走，所以我搞了一個 CountDownLatch。
這個代碼運行起來是沒有任何問題的，我們在日志中搜索“執行完成”，也能搜到 5 個，這個結果也能證明程序是正常結束的：
圖片
同時，可以看到運行時間是 4s。
示意圖大概是這樣的：
圖片
然后歪師傅看著這個代碼，發現了一個可以優化的地方：
圖片
這個地方從數據庫撈出來的數據，它們之間是沒有依賴關系的，也就是說它們之間也是可以并行執行的。
所以歪師傅把代碼改成了這樣：
圖片
在異步線程里面去處理這部分從數據庫中撈出來的數據，并行處理加快響應速度。
對應到圖片，大概就是這個意思：
圖片
把程序運行起來之后，日志變成了這樣：
圖片
我們搜索“執行完成”，也能搜到 5 個對應輸出。
而且我們就拿“任務2”來說：
圖片
當前線程pool-1-thread-3,---【任務2】開始執行---
當前線程pool-1-thread-3,---【任務2】執行完成---
當前線程pool-1-thread-1,【任務2】開始處理數據=1
當前線程pool-1-thread-2,【任務2】開始處理數據=2從日志輸出來看，任務 2 需要處理的兩個數據，確實是在不同的異步線程中處理數據，也實現了我的需求。
但是，程序運行直接就是到了 9.9ms：
圖片
這個優化這么牛逼的嗎？
從 4s 到了 9.9ms？
稍加分析，你會發現這里面是有問題的。
那么問題就來了，到底是啥問題呢？
你也分析分析大概是啥問題，別老是想著直接找答案啊。
問題就是由于轉異步了，所以 for 循環里面的任務中的 countDownLatch 很快就減到 0 了。
于是 await 繼續執行，所以很快就輸出了程序運行時間。
然而實際上子任務還在繼續執行，程序并沒有真正完成。
9.9ms 只是任務提交到線程池的時間，每個任務的數據處理時間還沒算呢：
圖片
從日志輸出上也可以看出，在輸出了 StopWatch 的日志后，各個任務還在處理數據。
這樣時間就顯得不夠真實。
那么我們應該怎么辦呢？
很簡單嘛，需要子任務真正執行完成后，父任務的 countDownLatch 才能進行 countDown 的動作。
具體實現上就是給子任務再加一個 countDownLatch 柵欄：
圖片
我們希望的運行結果應該是這樣的：
當前線程pool-1-thread-3,---【任務2】開始執行---
當前線程pool-1-thread-1,【任務2】開始處理數據=1
當前線程pool-1-thread-2,【任務2】開始處理數據=2
當前線程pool-1-thread-3,---【任務2】執行完成---即子任務全部完成之后，父任務才能算執行完成，這樣統計出來的時間才是準確的。
思路清晰，非常完美，再次運行，觀察日志我們會發現：
圖片
呃，怎么回事，日志怎么不輸出了？
是的，就是不輸出了。
不輸出了，就是踩到這個坑了。
不論你重啟多少次，都是這樣：日志不輸出了，程序就像是卡著了一樣。
坑在哪兒
上面這個 Demo 已經是我基于遇到的生產問題，極力簡化后的版本了。
現在，這個坑也已經呈現在你眼前了。
我們一起來分析一波。
首先，我問你：真的在線上遇到這種程序“假死”的問題，你會怎么辦？
早幾年，歪師傅的習慣是抱著代碼慢慢啃，試圖從代碼中找到端倪。
這樣確實是可以，但是通常來說效率不高。
現在我的習慣是直接把現場 dump 下來，分析現場。
比如在這個場景下，我們直觀上的感受是“卡住了”，那就 dump 一把線程，管它有棗沒棗，打一桿子再說：
圖片
通過 Dump 文件，可以發現線程池的線程都在 MainTest 的第 30 行上 parking ，處于等待狀態：
圖片
那么第 30 行是啥玩意？
圖片
這行代碼在干啥？
countDownLatchSub.await();
是父任務在等待子任務執行結束，運行 finally 代碼，把 countDownLatchSub 的計數 countDown 到 0，才會繼續執行：
圖片
所以現在的現象就是子任務的 countDownLatchSub 把父任務的攔住了。
換句話說就是父任務被攔住是因為子任務的 finally 代碼中的 countDownLatchSub.countDown() 方法沒有被執行。
好，那么最關鍵的問題就來了：為什么沒有執行？
你先別往下看，閉上眼睛在你的小腦瓜子里面推演一下，琢磨一下：finally 為什么沒有執行？
或者再換個更加接近真實的問題：子任務為什么沒有執行？
這個點，非常簡單，可以說一點就破。
琢磨明白了，這個坑的原理摸摸清楚了。
...
...
...
琢磨明白了嗎？你就刷刷往下看？
沒明白我再給你一個信息：需要結合線程池的參數和運行原理來分析。
什么？
你說線程池的運行原理你不清楚？
請你取關好嗎，你個假粉絲。
...
...
...
好，不管你“恍然大悟”了沒有，歪師傅給你講一下。
讓你知道“一點就破”這四個是怎么回事兒。
首先，我們把目光聚焦在線程池這里：
圖片
這個線程池核心線程數是 3，但是我們要提交 5 個任務到線程池去。
父任務哐哐哐，就把核心線程數占滿了。
接下來子任務也要往這個線程池提交任務怎么辦？
當然是進隊列等著了。
一進隊列，就完犢子。
到這里，我覺得你應該能想明白問題了。
應該給到我一個恍然大悟的表情，并配上“哦哦哦~”這樣的內心 OS。
你想想，父任務這個時候干啥？
是不是等在 countDownLatchSub.await() 這里。
而 countDownLatchSub.await() 什么時候能繼續執行？
是不是要所有子任務都執行 finally 后？
那么子任務現在在干啥？
是不是都在線程池里面的隊列等著被執行呢？
那線程池隊列里面的任務什么時候才執行？
是不是等著有空閑線程的時候？
那現在有沒有空閑線程？
沒有，所有的線程都去執行父任務去了。
那你想想，父任務這個時候干啥？
是不是等在 countDownLatchSub.await() 這里。
...
父任務在等子任務執行。
子任務在等線程池調度。
線程池在等父任務釋放線程。
閉環了，相互等待了，家人們。
這，就是坑。
現在把坑的原理摸清楚了，我在給你說一下真實的線上場景踩到這個坑是怎么樣的呢？
圖片
上游發起請求到微服務 A 的接口 1，該接口需要調用微服務 B 的接口 2。
但是微服務 B 的接口 2，需要從微服務 A 接口 3 獲取數據。
然而在微服務 A 內部，全局使用的是同一個自定義線程池。
更巧的是接口 1 和接口 3 內部都使用了這個自定義線程池做異步并行處理，想著是加快響應速度。
整個情況就變成了這樣：
- 接口 1 收到請求之后，把請求轉到自定義線程池中，然后等接口 2 返回。
- 接口 2 調用接口 3，并等待返回。
- 接口 3 里面把請求轉到了自定義線程池中，被放入了隊列。
- 線程池的線程都被接口 1 給占住了，沒有資源去執行隊列里面的接口 3 任務。
- 相互等待，一直僵持。
我們的 Demo 還是能比較清晰的看到父子任務之間的關系。
但是在這個微服務的場景下，在無形之間，就形成了不易察覺的父子任務關系。
所以就踩到了這個坑。
怎么避免
找到了坑的原因，解決方案就隨之而出了。
父子任務不要共用一個線程池，給子任務也搞一個自定義線程池就可以了：
圖片
運行起來看看日志：
圖片
首先整體運行時間只需要 2s 了，達到了我想要的效果。
另外，我們觀察一個具體的任務：
當前線程pool-1-thread-3,---【任務2】開始執行---
當前線程pool-2-thread-1,【任務2】開始處理數據=1
當前線程pool-2-thread-4,【任務2】開始處理數據=2
當前線程pool-1-thread-3,---【任務2】執行完成---日志輸出符合我們前面分析的，所有子任務執行完成后，父任務才打印執行完成，且子任務在不同的線程中執行。
而使用不同的線程池，換一個高大上的說法就叫做：線程池隔離。
而且在一個項目中，公用一個線程池，也是一個埋坑的邏輯。
至少給你覺得關鍵的邏輯，單獨分配一個線程池吧。
避免出現線程池的線程都在執行非核心邏輯了，反而重要的任務在隊列里面排隊去了。
這就有點不合理了。
最后，一句話總結這個問題：
如果線程池的任務之間存在父子關系，那么請不要使用同一個線程池。如果使用了同一個線程池，可能會因為子任務進了隊列，導致父任務一直等待，出現假死現象。
