有的線程它死了，于是它變成一道面試題。

有些線程它活著，但它躺在池中碌碌無為；

有的線程它死了，于是它變成一道面試題。

這次的文章，要從一次阿里的面試說起。


我記得那天是周一，剛剛經(jīng)歷過周末過的放松，干勁十足的我正在鍵盤上瘋狂的輸出。這時，我的手機響了起來，拿起一看，是來自杭州的電話，心想這次是要給我推薦股票呢還是要讓我貸款呢。我接起了電話，準備“調(diào)戲一番”。那邊響起一個聲音:"你好，請問是xxx嗎？這邊是杭州阿里巴巴，現(xiàn)在有時間進行電話面試嗎?"。說實在的，聽完這句話后，我感覺我已經(jīng)身在杭州，干勁十足的在杭州的阿里的工位上"修福報"。但是我現(xiàn)在正在瘋狂輸出，沒有時間，于是我說:"不好意思，現(xiàn)在沒有時間，可以約在今天晚上8點鐘嗎?".


晚上如約接到了電話。我們直奔主題，在你來我往中進行了友好的技術(shù)交流。具體的面試過程就不詳述了，后面有機會整理一份面試分享。整個面試過程中，有這么一道題給我留下了深刻的印象:
一個線程池中的線程異常了，那么線程池會怎么處理這個線程?
需要說明一下,文中討論的線程池都是Executors線程池。

對于Executors線程池我可以說是爛熟于心，因為工作中用的比較的多，閱讀過其源碼。也是我作為面試官時必問的幾個范圍之一，比如以下問題:
了解JDK Executors線程池嗎?
知道JDK提供了哪些默認的實現(xiàn)嗎？
看過阿里巴巴java開發(fā)手冊嗎？知道為啥不允許使用默認的實現(xiàn)嗎？
你們沒有用默認的吧?那來介紹一下你們自定義線程池的幾個常用參數(shù)唄？
你這個幾個參數(shù)的值是怎么得來的呀？算出來的？怎么算出來的？
線程池里面的任務是IO密集型的還是計算密集型的呢？
好，現(xiàn)在我們有一個自定義線程池了，來說一下你這個線程池的工作流程唄？
那你這個線程池滿了怎么辦呀？拒絕？咋拒絕？有哪些拒絕策略呢？
別緊張,隨便說兩個就行。
......
回到開始說的阿里巴巴java開發(fā)手冊不允許使用默認實現(xiàn)，你回答說可能會引起OOM,那我們聊聊JVM吧
......


阿里巴巴java開發(fā)手冊關(guān)于線程池創(chuàng)建的建議


這一系列關(guān)于線程池的連環(huán)炮，就是我作為面試官時必問的幾個問題。別問為什么，因為我們的招聘JD上明確寫了：熟悉多線程編程。而這些問題，我覺得是熟悉多線程編程的基礎。這里我也不解答了，這種文章網(wǎng)上還是挺多的，可以去了解一下。

這塊真的很重要，我也多次給我的小伙伴強調(diào):

?

?




來吧，一起分析一波

好了現(xiàn)在回到阿里的面試官問我的這道面試題:
一個線程池中的線程異常了，那么線程池會怎么處理這個線程?
先說說我當時的回答，因為心里沒底，我的回答很猶豫也很爛！如下:


我的回答總結(jié)起來三句話:
1.拋出堆棧異常?---這句話對了一半！
2.不影響其他線程任務?---這句話全對！
3.這個線程會被放回線程池?---這句話全錯！
測試用例寫起來



拋出堆棧異常為啥對了一半?

先讓程序跑起來，我們用事實說話:

從執(zhí)行結(jié)果我們看出
當執(zhí)行方式是execute時,可以看到堆棧異常的輸出。
當執(zhí)行方式是submit時,堆棧異常沒有輸出。
那么我們怎么拿到submit執(zhí)行方式的堆棧異常呢，看圖說話:

所以，現(xiàn)在知道為什么回答:拋出堆棧異常只對了一半吧。
execute方法執(zhí)行時，會拋出(打印)堆棧異常。
submit方法執(zhí)行時，返回結(jié)果封裝在future中，如果調(diào)用future.get()方法則必須進行異常捕獲，從而可以拋出(打印)堆棧異常。
你以為這一部分寫到這里就完事了？那不行啊，你心里沒有一個疑問嗎？為啥execute直接拋出異常，submit沒有直接拋出異常呢？

源碼之下無秘密:
當執(zhí)行方式是executes時:
在java.util.concurrent.ThreadPoolExecutor#runWorker中拋出了異常:

在_java.lang.ThreadGroup#uncaughtException_進行了異常處理:

這個uncaughtException是何許人也,看java doc上咋說的：

這個方法是JVM調(diào)用的，我們只需要指定我們想要的處理方式即可。
那我們怎么指定呢:
//直接new Thread()的時候
Thread t=newThread();
t.setUncaughtExceptionHandler(newThread.UncaughtExceptionHandler()
{publicvoiduncaughtException(Thread t, Throwable e){
//根據(jù)業(yè)務場景，做你想做的 }
});
//線程池的時候:
ExecutorService threadPool = Executors.newFixedThreadPool(1, thread -> {
Thread t =newThread(thread);
t.setUncaughtExceptionHandler((t1, e) ->
System.out.println("根據(jù)業(yè)務場景，做你想做的:"+ e.getMessage()));returnt;}
);

當執(zhí)行方式是submit時:


其本質(zhì)也是調(diào)用了execute方法，所以它還是回到_java.util.concurrent.ThreadPoolExecutor#runWorker_方法:

向前，繼續(xù)跟進去看看：

_java.util.concurrent.FutureTask#setException_干啥了啊，瞅一眼：

深呼吸，整理好思路，我們馬上走向最終的真相:

好了，第一個議題【拋出堆棧異常為啥對了一半?】討論完畢。在源碼里面走了一趟，現(xiàn)在我們可以給出這一部分的滿分答案了。

不影響其他線程任務，回答正確

這一部分我們直接上代碼，運行起來看結(jié)果吧:

代碼和運行結(jié)果是不會騙人的:
線程池中一個線程異常了后，不影響其他線程任務
大家注意線程名稱這個細節(jié):1,2,3,4,6。魔鬼都在細節(jié)里啊，這個點我下面會講，先在這里把問題拋出來:我就納悶了,怎么沒有5啊?!

這個線程會被放回線程池為啥全錯了？

我們?nèi)ピ创a里面尋找答案:

讓源碼給出答案:

5號線程去哪里了?

new Worker()方法會告訴你:5去哪里了。

再配上這張由我這個靈魂畫師親自操刀畫的圖，一起食用，味道更佳：

?

?

現(xiàn)在知道為啥：我回答這個線程會被放回線程池為啥全錯了吧。還附帶送你一個線程名稱變化的細節(jié)，不客氣。

總結(jié)一下
當一個線程池里面的線程異常后:
當執(zhí)行方式是execute時,可以看到堆棧異常的輸出。
當執(zhí)行方式是submit時,堆棧異常沒有輸出。但是調(diào)用Future.get()方法時，可以捕獲到異常。
不會影響線程池里面其他線程的正常執(zhí)行。
線程池會把這個線程移除掉，并創(chuàng)建一個新的線程放到線程池中。
不要背答案，要理解，要深入，上面說完后記得在問問面試官，需要我從源碼的角度講一講嗎?這逼裝的，禮貌而不失風度。
以上，我關(guān)于《一個線程池中的線程異常了，那么線程池會怎么處理這個線程?》這個問題的見解就表達完畢，僅代表個人觀點，歡迎有不同意見的小伙伴，一起討論，一起進步。

最后說一點

這篇文章是我上周五推完上一篇文章之后就在構(gòu)思并且著手準備了。大部分內(nèi)容都是思考于晚上睡覺前的半小時，寫于周末和工作日的早上早起的一小時。

其實想到寫什么內(nèi)容并不難，難的是你對內(nèi)容的把控。關(guān)于技術(shù)性的語言，我是反復推敲，查閱大量文章來進行證偽，總之慎言慎言再慎言，畢竟做技術(shù)，我認為是一件非常嚴謹?shù)氖虑椋页３Ｏ胂笞约壕褪窃诠蕦m修文物的工匠，在工匠精神的認知上，目前我可能和他們還差的有點遠，但是我時常以工匠精神要求自己。就像我在群里表達的：對于技術(shù)文章（因為我偶爾也會荒腔走板的聊一聊生活，寫一寫書評，影評），我盡量保證周推，全力保證質(zhì)量。

最后，再感嘆一次:

有些線程它活著，但它躺在池中碌碌無為；
有些線程也活著，但它一刻不停忙到飛起；
有的線程它死了，被拋棄，被回收，
但是它無怨無悔，

因為它是死在執(zhí)行任務的路上，
它憑借自己最后的一聲吶喊
“為了新兄弟，移除我吧！”
最后，變成一道面試題。

我還沒答上來。


歡迎關(guān)注公眾號【why技術(shù)】。在這里我會分享一些技術(shù)相關(guān)的東西，主攻java方向，用匠心敲代碼，對每一行代碼負責。偶爾也會荒腔走板的聊一聊生活，寫一寫書評，影評。愿你我共同進步。

• ? 上一篇：程序員過關(guān)斬將--自定義線程池來實現(xiàn)文檔轉(zhuǎn)碼
• ? 下一篇：【思維論01】如何讓自己像打王者榮耀一樣發(fā)了瘋、石樂志的學習？