有些線程它活著,但它躺在池中碌碌無為;
有的線程它死了,於是它變成一道面試題。
這次的文章,要從一次阿里的面試說起。
我記得那天是週一,剛剛經歷過週末過的放鬆,幹勁十足的我正在鍵盤上瘋狂的輸出。這時,我的手機響了起來,拿起一看,是來自杭州的電話,心想這次是要給我推薦股票呢還是要讓我貸款呢。我接起了電話,準備“調戲一番”。那邊響起一個聲音:"你好,請問是xxx嗎?這邊是杭州阿里巴巴,現在有時間進行電話面試嗎?"。說實在的,聽完這句話後,我感覺我已經身在杭州,幹勁十足的在杭州的阿里的工位上"修福報"。但是我現在正在瘋狂輸出,沒有時間,於是我說:"不好意思,現在沒有時間,可以約在今天晚上8點鐘嗎?".
晚上如約接到了電話。我們直奔主題,在你來我往中進行了友好的技術交流。具體的面試過程就不詳述了,後面有機會整理一份面試分享。整個面試過程中,有這麼一道題給我留下了深刻的印象:
一個線程池中的線程異常了,那麼線程池會怎麼處理這個線程?
需要說明一下,文中討論的線程池都是Executors線程池。
對於Executors線程池我可以說是爛熟於心,因為工作中用的比較的多,閱讀過其源碼。也是我作為面試官時必問的幾個範圍之一,比如以下問題:
瞭解JDK Executors線程池嗎?知道JDK提供了哪些默認的實現嗎?看過阿里巴巴java開發手冊嗎?知道為啥不允許使用默認的實現嗎?你們沒有用默認的吧?那來介紹一下你們自定義線程池的幾個常用參數唄?你這個幾個參數的值是怎麼得來的呀?算出來的?怎麼算出來的?線程池裡面的任務是IO密集型的還是計算密集型的呢?好,現在我們有一個自定義線程池了,來說一下你這個線程池的工作流程唄?那你這個線程池滿了怎麼辦呀?拒絕?咋拒絕?有哪些拒絕策略呢?別緊張,隨便說兩個就行。......回到開始說的阿里巴巴java開發手冊不允許使用默認實現,你回答說可能會引起OOM,那我們聊聊JVM吧......
阿里巴巴java開發手冊關於線程池創建的建議
這一系列關於線程池的連環炮,就是我作為面試官時必問的幾個問題。別問為什麼,因為我們的招聘JD上明確寫了:熟悉多線程編程。而這些問題,我覺得是熟悉多線程編程的基礎。這裡我也不解答了,這種文章網上還是挺多的,可以去了解一下。
這塊真的很重要,我也多次給我的小夥伴強調:
來吧,一起分析一波
好了現在回到阿里的面試官問我的這道面試題:
一個線程池中的線程異常了,那麼線程池會怎麼處理這個線程?先說說我當時的回答,因為心裡沒底,我的回答很猶豫也很爛!如下:
我的回答總結起來三句話:
1.拋出堆棧異常 ---這句話對了一半!2.不影響其他線程任務 ---這句話全對!3.這個線程會被放回線程池 ---這句話全錯!
測試用例寫起來
拋出堆棧異常為啥對了一半?
先讓程序跑起來,我們用事實說話:
從執行結果我們看出
當執行方式是execute時,可以看到堆棧異常的輸出。當執行方式是submit時,堆棧異常沒有輸出。那麼我們怎麼拿到submit執行方式的堆棧異常呢,看圖說話:
所以,現在知道為什麼回答:拋出堆棧異常只對了一半吧。execute方法執行時,會拋出(打印)堆棧異常。submit方法執行時,返回結果封裝在future中,如果調用future.get()方法則必須進行異常捕獲,從而可以拋出(打印)堆棧異常。你以為這一部分寫到這裡就完事了?那不行啊,你心裡沒有一個疑問嗎?為啥execute直接拋出異常,submit沒有直接拋出異常呢?
源碼之下無秘密:當執行方式是executes時:在java.util.concurrent.ThreadPoolExecutor#runWorker中拋出了異常:
在java.lang.ThreadGroup#uncaughtException進行了異常處理:
這個uncaughtException是何許人也,看java doc上咋說的:
這個方法是JVM調用的,我們只需要指定我們想要的處理方式即可。那我們怎麼指定呢:
//直接new Thread()的時候Thread t=newThread();t.setUncaughtExceptionHandler(newThread.UncaughtExceptionHandler(){publicvoiduncaughtException(Thread t, Throwable e){//根據業務場景,做你想做的 }});
//線程池的時候:ExecutorService threadPool = Executors.newFixedThreadPool(1, thread -> {Thread t =newThread(thread);t.setUncaughtExceptionHandler((t1, e) ->System.out.println("根據業務場景,做你想做的:"+ e.getMessage()));returnt;});
當執行方式是submit時:
其本質也是調用了execute方法,所以它還是回到java.util.concurrent.ThreadPoolExecutor#runWorker方法:
向前,繼續跟進去看看:
java.util.concurrent.FutureTask#setException幹啥了啊,瞅一眼:
深呼吸,整理好思路,我們馬上走向最終的真相:
好了,第一個議題【拋出堆棧異常為啥對了一半?】討論完畢。在源碼裡面走了一趟,現在我們可以給出這一部分的滿分答案了。
不影響其他線程任務,回答正確
這一部分我們直接上代碼,運行起來看結果吧:
代碼和運行結果是不會騙人的:線程池中一個線程異常了後,不影響其他線程任務大家注意線程名稱這個細節:1,2,3,4,6。魔鬼都在細節裡啊,這個點我下面會講,先在這裡把問題拋出來:我就納悶了,怎麼沒有5啊?!
這個線程會被放回線程池為啥全錯了?
我們去源碼裡面尋找答案:
讓源碼給出答案:
5號線程去哪裡了?
new Worker()方法會告訴你:5去哪裡了。
再配上這張由我這個靈魂畫師親自操刀畫的圖,一起食用,味道更佳:
現在知道為啥:我回答這個線程會被放回線程池為啥全錯了吧。還附帶送你一個線程名稱變化的細節,不客氣。
總結一下
當一個線程池裡面的線程異常後:當執行方式是execute時,可以看到堆棧異常的輸出。當執行方式是submit時,堆棧異常沒有輸出。但是調用Future.get()方法時,可以捕獲到異常。不會影響線程池裡面其他線程的正常執行。線程池會把這個線程移除掉,並創建一個新的線程放到線程池中。不要背答案,要理解,要深入,上面說完後記得在問問面試官,需要我從源碼的角度講一講嗎?這逼裝的,禮貌而不失風度。
來源:https://www.cnblogs.com/thisiswhy/p/12221335.html
閱讀更多 Java架構學習交流 的文章