----本文首發(fā)于公眾號顿肺,關注公眾號閱讀體驗更佳
有些線程它活著戏溺,但它躺在池中碌碌無為渣蜗;
有的線程它死了,于是它變成一道面試題旷祸。
這次的文章耕拷,要從一次阿里的面試說起。
我記得那天是周一托享,剛剛經(jīng)歷過周末過的放松骚烧,干勁十足的我正在鍵盤上瘋狂的輸出。這時闰围,我的手機響了起來赃绊,拿起一看,是來自杭州的電話辫诅,心想這次是要給我推薦股票呢還是要讓我貸款呢凭戴。我接起了電話,準備“調(diào)戲一番”炕矮。那邊響起一個聲音:"你好,請問是xxx嗎者冤?這邊是杭州阿里巴巴肤视,現(xiàn)在有時間進行電話面試嗎?"。說實在的涉枫,聽完這句話后邢滑,我感覺我已經(jīng)身在杭州,干勁十足的在杭州的阿里的工位上"修福報"愿汰。但是我現(xiàn)在正在瘋狂輸出困后,沒有時間,于是我說:"不好意思衬廷,現(xiàn)在沒有時間摇予,可以約在今天晚上8點鐘嗎?".
晚上如約接到了電話。我們直奔主題吗跋,在你來我往中進行了友好的技術交流侧戴。具體的面試過程就不詳述了,后面有機會整理一份面試分享跌宛。整個面試過程中酗宋,有這么一道題給我留下了深刻的印象:
一個線程池中的線程異常了,那么線程池會怎么處理這個線程?
需要說明一下,文中討論的線程池都是Executors線程池疆拘。
對于Executors線程池我可以說是爛熟于心蜕猫,因為工作中用的比較的多,閱讀過其源碼哎迄。也是我作為面試官時必問的幾個范圍之一回右,比如以下問題:
了解JDK Executors線程池嗎?
知道JDK提供了哪些默認的實現(xiàn)嗎侧漓?
看過阿里巴巴java開發(fā)手冊嗎?知道為啥不允許使用默認的實現(xiàn)嗎巍虫?
你們沒有用默認的吧?那來介紹一下你們自定義線程池的幾個常用參數(shù)唄惧互?
你這個幾個參數(shù)的值是怎么得來的呀?算出來的租漂?怎么算出來的阶女?
線程池里面的任務是IO密集型的還是計算密集型的呢?
好哩治,現(xiàn)在我們有一個自定義線程池了秃踩,來說一下你這個線程池的工作流程唄?
那你這個線程池滿了怎么辦呀业筏?拒絕憔杨?咋拒絕?有哪些拒絕策略呢蒜胖?
別緊張,隨便說兩個就行消别。
......
回到開始說的阿里巴巴java開發(fā)手冊不允許使用默認實現(xiàn),你回答說可能會引起OOM,那我們聊聊JVM吧
......
這一系列關于線程池的連環(huán)炮台谢,就是我作為面試官時必問的幾個問題寻狂。別問為什么,因為我們的招聘JD上明確寫了:熟悉多線程編程朋沮。而這些問題蛇券,我覺得是熟悉多線程編程的基礎。這里我也不解答了樊拓,這種文章網(wǎng)上還是挺多的纠亚,可以去了解一下。
這塊真的很重要筋夏,我也多次給我的小伙伴強調(diào):
來吧蒂胞,一起分析一波
好了現(xiàn)在回到阿里的面試官問我的這道面試題:
一個線程池中的線程異常了,那么線程池會怎么處理這個線程?
先說說我當時的回答叁丧,因為心里沒底啤誊,我的回答很猶豫也很爛!如下:
我的回答總結起來三句話:
1.拋出堆棧異常?---這句話對了一半拥娄!
2.不影響其他線程任務---這句話全對蚊锹!
3.這個線程會被放回線程池---這句話全錯!
測試用例寫起來
拋出堆棧異常為啥對了一半?
先讓程序跑起來稚瘾,我們用事實說話:
從執(zhí)行結果我們看出
當執(zhí)行方式是execute時,可以看到堆棧異常的輸出牡昆。
當執(zhí)行方式是submit時,堆棧異常沒有輸出。
那么我們怎么拿到submit執(zhí)行方式的堆棧異常呢,看圖說話:
所以丢烘,現(xiàn)在知道為什么回答:拋出堆棧異常只對了一半吧柱宦。
execute方法執(zhí)行時,會拋出(打印)堆棧異常播瞳。
submit方法執(zhí)行時掸刊,返回結果封裝在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, r -> {
Thread t =newThread(r);
t.setUncaughtExceptionHandler((t1,?e)?->?
System.out.println("根據(jù)業(yè)務場景驯击,做你想做的:"+?e.getMessage()));returnt;}
);
當執(zhí)行方式是submit時:
其本質也是調(diào)用了execute方法,所以它還是回到java.util.concurrent.ThreadPoolExecutor#runWorker方法:
向前耐亏,繼續(xù)跟進去看看:
java.util.concurrent.FutureTask#setException干啥了啊余耽,瞅一眼:
深呼吸,整理好思路苹熏,我們馬上走向最終的真相:
好了,第一個議題【拋出堆棧異常為啥對了一半?】討論完畢币喧。在源碼里面走了一趟轨域,現(xiàn)在我們可以給出這一部分的滿分答案了。
不影響其他線程任務杀餐,回答正確
這一部分我們直接上代碼干发,運行起來看結果吧:
代碼和運行結果是不會騙人的:
線程池中一個線程異常了后,不影響其他線程任務
大家注意線程名稱這個細節(jié):1,2,3,4,6史翘。魔鬼都在細節(jié)里啊枉长,這個點我下面會講,先在這里把問題拋出來:我就納悶了,怎么沒有5啊?!
這個線程會被放回線程池為啥全錯了琼讽?
我們?nèi)ピ创a里面尋找答案:
讓源碼給出答案:
5號線程去哪里了?
new Worker()方法會告訴你:5去哪里了必峰。
再配上這張由我這個靈魂畫師親自操刀畫的圖,一起食用钻蹬,味道更佳:
現(xiàn)在知道為啥:我回答這個線程會被放回線程池為啥全錯了吧吼蚁。還附帶送你一個線程名稱變化的細節(jié),不客氣问欠。
總結一下
當一個線程池里面的線程異常后:
當執(zhí)行方式是execute時,可以看到堆棧異常的輸出肝匆。
當執(zhí)行方式是submit時,堆棧異常沒有輸出粒蜈。但是調(diào)用Future.get()方法時,可以捕獲到異常旗国。
不會影響線程池里面其他線程的正常執(zhí)行枯怖。
線程池會把這個線程移除掉,并創(chuàng)建一個新的線程放到線程池中能曾。
不要背答案度硝,要理解,要深入借浊,上面說完后記得在問問面試官塘淑,需要我從源碼的角度講一講嗎?這逼裝的,禮貌而不失風度蚂斤。
以上存捺,我關于《一個線程池中的線程異常了,那么線程池會怎么處理這個線程?》這個問題的見解就表達完畢曙蒸,僅代表個人觀點捌治,歡迎有不同意見的小伙伴,一起討論纽窟,一起進步肖油。
最后說一點
這篇文章是我上周五推完上一篇文章之后就在構思并且著手準備了。大部分內(nèi)容都是思考于晚上睡覺前的半小時臂港,寫于周末和工作日的早上早起的一小時森枪。
其實想到寫什么內(nèi)容并不難,難的是你對內(nèi)容的把控审孽。關于技術性的語言县袱,我是反復推敲,查閱大量文章來進行證偽佑力,總之慎言慎言再慎言式散,畢竟做技術,我認為是一件非常嚴謹?shù)氖虑榇虿页3O胂笞约壕褪窃诠蕦m修文物的工匠暴拄,在工匠精神的認知上,目前我可能和他們還差的有點遠编饺,但是我時常以工匠精神要求自己乖篷。就像我在群里表達的:對于技術文章(因為我偶爾也會荒腔走板的聊一聊生活,寫一寫書評反肋,影評)那伐,我盡量保證周推,全力保證質量。
最后罕邀,再感嘆一次:
有些線程它活著畅形,但它躺在池中碌碌無為;
有些線程也活著诉探,但它一刻不停忙到飛起日熬;
有的線程它死了,被拋棄肾胯,被回收竖席,
但是它無怨無悔,
因為它是死在執(zhí)行任務的路上敬肚,
它憑借自己最后的一聲吶喊
“為了新兄弟毕荐,移除我吧!”
最后艳馒,變成一道面試題憎亚。
我還沒答上來。