有的線程它死了，于是它變成一道面試題
有些線程它活著，但它躺在池中碌碌無(wú)為；
有的線程它死了，于是它變成一道面試題。
這次的文章，要從一次阿里巴巴的面試說(shuō)起。
我記得那天是周一，剛剛經(jīng)歷過(guò)周末過(guò)的放松，干勁十足的我正在鍵盤上瘋狂的輸出。這時(shí)，我的手機(jī)響了起來(lái)，拿起一看，是來(lái)自杭州的電話，心想這次是要給我推薦股票呢還是要讓我貸款呢。我接起了電話，準(zhǔn)備調(diào)戲一番。那邊響起一個(gè)聲音:"你好，請(qǐng)問(wèn)是xxx嗎？這邊是杭州阿里巴巴，現(xiàn)在有時(shí)間進(jìn)行電話面試嗎?"。說(shuō)實(shí)在的，聽完這句話后，我感覺(jué)我已經(jīng)身在杭州，干勁十足的在杭州的阿里的工位上"修福報(bào)"。但是我現(xiàn)在正在瘋狂輸出，沒(méi)有時(shí)間，于是我說(shuō):"不好意思，現(xiàn)在沒(méi)有時(shí)間，可以約在今天晚上8點(diǎn)鐘嗎?".
晚上如約接到了電話。我們直奔主題，在你來(lái)我往中進(jìn)行了友好的技術(shù)交流。具體的面試過(guò)程就不詳述了，后面有機(jī)會(huì)整理一份面試分享。整個(gè)面試過(guò)程中，有這么一道題給我留下了深刻的印象:
一個(gè)線程池中的線程異常了，那么線程池會(huì)怎么處理這個(gè)線程?
需要說(shuō)明一下,文中討論的線程池都是Executors線程池。
對(duì)于Executors線程池我可以說(shuō)是爛熟于心，因?yàn)楣ぷ髦杏玫谋容^的多，閱讀過(guò)其源碼。也是我作為面試官時(shí)必問(wèn)的幾個(gè)范圍之一，比如以下問(wèn)題:
了解JDK Executors線程池嗎?
知道JDK提供了哪些默認(rèn)的實(shí)現(xiàn)嗎？
看過(guò)阿里巴巴java開發(fā)手冊(cè)嗎？知道為啥不允許使用默認(rèn)的實(shí)現(xiàn)嗎？
你們沒(méi)有用默認(rèn)的吧?那來(lái)介紹一下你們自定義線程池的幾個(gè)常用參數(shù)唄？
你這個(gè)幾個(gè)參數(shù)的值是怎么得來(lái)的呀？算出來(lái)的？怎么算出來(lái)的？
線程池里面的任務(wù)是IO密集型的還是計(jì)算密集型的呢？
好，現(xiàn)在我們有一個(gè)自定義線程池了，來(lái)說(shuō)一下你這個(gè)線程池的工作流程唄？
那你這個(gè)線程池滿了怎么辦呀？拒絕？咋拒絕？有哪些拒絕策略呢？
別緊張,隨便說(shuō)兩個(gè)就行。
......
回到開始說(shuō)的阿里巴巴java開發(fā)手冊(cè)不允許使用默認(rèn)實(shí)現(xiàn)，你回答說(shuō)可能會(huì)引起OOM,那我們聊聊JVM吧
......
阿里巴巴java開發(fā)手冊(cè)關(guān)于線程池創(chuàng)建的建議
這一系列關(guān)于線程池的連環(huán)炮，就是我作為面試官時(shí)必問(wèn)的幾個(gè)問(wèn)題。別問(wèn)為什么，因?yàn)槲覀兊恼衅窲D上明確寫了：熟悉多線程編程。而這些問(wèn)題，我覺(jué)得是熟悉多線程編程的基礎(chǔ)。這里我也不解答了，這種文章網(wǎng)上還是挺多的，可以去了解一下。
這塊真的很重要，我也多次給我的小伙伴強(qiáng)調(diào):
1
來(lái)吧，一起分析一波
好了現(xiàn)在回到阿里的面試官問(wèn)我的這道面試題:
一個(gè)線程池中的線程異常了，那么線程池會(huì)怎么處理這個(gè)線程?
先說(shuō)說(shuō)我當(dāng)時(shí)的回答，因?yàn)樾睦餂](méi)底，我的回答很猶豫也很爛！如下:
我的回答總結(jié)起來(lái)三句話:
1.拋出堆棧異常 ---這句話對(duì)了一半！
2.不影響其他線程任務(wù) ---這句話全對(duì)！
3.這個(gè)線程會(huì)被放回線程池---這句話全錯(cuò)！
1
測(cè)試用例寫起來(lái)
再提供一個(gè)復(fù)制粘貼直接運(yùn)行版本:
/*** @Author: why技術(shù)* @Date: 2019/9/6 22:25*/public class ExecutorsTest {public static void main(String[] args) {ThreadPoolTaskExecutor executorService = buildThreadPoolTaskExecutor();executorService.execute(() -> sayHi("execute"));executorService.submit(() -> sayHi("submit"));}private static void sayHi(String name) {String printStr = "【thread-name:" + Thread.currentThread().getName() + ",執(zhí)行方式:" + name+"】";System.out.println(printStr);throw new RuntimeException(printStr + ",我異常啦!哈哈哈!");}private static ThreadPoolTaskExecutor buildThreadPoolTaskExecutor() {ThreadPoolTaskExecutor executorService = new ThreadPoolTaskExecutor();executorService.setThreadNamePrefix("(公眾號(hào)-why技術(shù))-");executorService.setCorePoolSize(5);executorService.setMaxPoolSize(10);executorService.setQueueCapacity(1000);executorService.setKeepAliveSeconds(30);executorService.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());executorService.initialize();return executorService;}}
1
拋出堆棧異常為啥對(duì)了一半?
先讓程序跑起來(lái)，我們用事實(shí)說(shuō)話:
從執(zhí)行結(jié)果我們看出
當(dāng)執(zhí)行方式是execute時(shí),可以看到堆棧異常的輸出。
當(dāng)執(zhí)行方式是submit時(shí),堆棧異常沒(méi)有輸出。
那么我們?cè)趺茨玫絪ubmit執(zhí)行方式的堆棧異常呢，看圖說(shuō)話:
所以，現(xiàn)在知道為什么回答:拋出堆棧異常只對(duì)了一半吧。
execute方法執(zhí)行時(shí)，會(huì)拋出(打印)堆棧異常。
submit方法執(zhí)行時(shí)，返回結(jié)果封裝在future中，如果調(diào)用future.get()方法則必須進(jìn)行異常捕獲，從而可以拋出(打印)堆棧異常。
你以為這一部分寫到這里就完事了？那不行啊，你心里沒(méi)有一個(gè)疑問(wèn)嗎？為啥execute直接拋出異常，submit沒(méi)有直接拋出異常呢？
源碼之下無(wú)秘密:
當(dāng)執(zhí)行方式是executes時(shí):
在java.util.concurrent.ThreadPoolExecutor#runWorker中拋出了異常:
在java.lang.ThreadGroup#uncaughtException進(jìn)行了異常處理:
這個(gè)uncaughtException是何許人也,看java doc上咋說(shuō)的：
這個(gè)方法是JVM調(diào)用的，我們只需要指定我們想要的處理方式即可。
那我們?cè)趺粗付?
//直接new Thread()的時(shí)候Thread t = new Thread();t.setUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {public void uncaughtException(Thread t, Throwable e) {//根據(jù)業(yè)務(wù)場(chǎng)景，做你想做的}});
//線程池的時(shí)候:ExecutorService threadPool = Executors.newFixedThreadPool(1, r -> {Thread t = new Thread(r);t.setUncaughtExceptionHandler((t1, e) -> System.out.println("根據(jù)業(yè)務(wù)場(chǎng)景，做你想做的:" + e.getMessage()));return t;});
其本質(zhì)也是調(diào)用了execute方法，所以它還是回到java.util.concurrent.ThreadPoolExecutor#runWorker方法:
向前，繼續(xù)跟進(jìn)去看看：
java.util.concurrent.FutureTask#setException干啥了啊，瞅一眼：
深呼吸，整理好思路，我們馬上走向最終的真相:
好了，第一個(gè)議題【拋出堆棧異常為啥對(duì)了一半?】討論完畢。在源碼里面走了一趟，現(xiàn)在我們可以給出這一部分的滿分答案了。
1
不影響其他線程任務(wù)，回答正確
一部分我們直接上代碼，運(yùn)行起來(lái)看結(jié)果吧:
代碼和運(yùn)行結(jié)果是不會(huì)騙人的:
線程池中一個(gè)線程異常了后，不影響其他線程任務(wù)
大家注意線程名稱這個(gè)細(xì)節(jié):1,2,3,4,6。魔鬼都在細(xì)節(jié)里啊，這個(gè)點(diǎn)我下面會(huì)講，先在這里把問(wèn)題拋出來(lái):我就納悶了,怎么沒(méi)有5啊?!
1
這個(gè)線程會(huì)被放回線程池為啥全錯(cuò)了？
我們?nèi)ピ创a里面尋找答案:
讓源碼給出答案:
5號(hào)線程去哪里了?
new Worker()方法會(huì)告訴你:5去哪里了。
再配上這張由我這個(gè)靈魂畫師親自操刀畫的圖，一起食用，味道更佳:
現(xiàn)在我們知道為啥：我回答這個(gè)線程會(huì)被放回線程池為啥全錯(cuò)了吧。還附送你一個(gè)線程名稱變化的細(xì)節(jié)，不客氣，關(guān)注一下就好。
1
總結(jié)一下
當(dāng)執(zhí)行方式是execute時(shí),可以看到堆棧異常的輸出。
當(dāng)執(zhí)行方式是submit時(shí),堆棧異常沒(méi)有輸出。但是調(diào)用Future.get()方法時(shí)，可以捕獲到異常。
不會(huì)影響線程池里面其他線程的正常執(zhí)行。
線程池會(huì)把這個(gè)線程移除掉，并創(chuàng)建一個(gè)新的線程放到線程池中。
不要背答案，要理解，要深入，上面說(shuō)完后記得在問(wèn)問(wèn)面試官，需要我從源碼的角度講一講嗎?這逼裝的，禮貌而不失風(fēng)度。
以上，我關(guān)于《一個(gè)線程池中的線程異常了，那么線程池會(huì)怎么處理這個(gè)線程?》這個(gè)問(wèn)題的見解就表達(dá)完畢，僅代表個(gè)人觀點(diǎn)，歡迎有不同意見的小伙伴，一起討論，一起進(jìn)步。
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！
下載文檔
