一道面試題

我一年前寫過這篇文章《有的線程它死了，于是它變成一道面試題》，這是早期作品，遣詞造句，排版行文都有一點(diǎn)稚嫩，但是承蒙厚愛，還是有很多人看過。

甚至已經(jīng)進(jìn)入了某網(wǎng)紅公司的面試題庫里面。

本文相當(dāng)于是對(duì)上面這篇文章的一個(gè)補(bǔ)充。

現(xiàn)在先回顧一下這篇文章拋出的問題和問題的答案：

一個(gè)線程池中的線程異常了，那么線程池會(huì)怎么處理這個(gè)線程?

這個(gè)題是我遇到的一個(gè)真實(shí)的面試題，當(dāng)時(shí)并沒有回答的很好。然后通過上面的文章，我在源碼中尋找到了答案。

先給大家看兩個(gè)案例。

sayHi 方法是會(huì)拋出運(yùn)行時(shí)異常的。

當(dāng)執(zhí)行方式是 execute 方法時(shí)，在控制臺(tái)會(huì)打印堆棧異常：

當(dāng)執(zhí)行方式是 submit 方法時(shí)，在控制臺(tái)不會(huì)打印堆棧異常：

那么怎么獲取這個(gè) submit 方法提交時(shí)的異常信息呢？

得調(diào)用返回值 future 的 get 方法：

具體原因，我在之前的文章里面詳細(xì)分析過，就不贅述了，直接看結(jié)論：

然后一個(gè)讀者找我聊天，說為什么他這樣寫，通過 future.get 方法沒有拋出異常呢，和我文章里面說的不一樣呢？

我說：那肯定是你操作不對(duì)，你把代碼發(fā)給我看看。

然后我收到了一份這樣的代碼：

public?class?ExecutorsTest?{

????public?static?void?main(String[]?args)?{
????????ThreadPoolExecutor?executorService?=?new?ThreadPoolExecutor(2,?2,
????????????????30,?TimeUnit.SECONDS,?new?ArrayBlockingQueue<>(10));
????????Future?future?=?executorService.submit(()?->?{
????????????try?{
????????????????sayHi("submit");
????????????}?catch?(Exception?e)?{
????????????????System.out.println("sayHi?Exception");
????????????????e.printStackTrace();
????????????}
????????});

????????try?{
????????????future.get();
????????}?catch?(Exception?e)?{
????????????System.out.println("future.get?Exception");
????????????e.printStackTrace();
????????}
????}

????private?static?void?sayHi(String?name)?throws?RuntimeException?{
????????String?printStr?=?"【thread-name:"?+?Thread.currentThread().getName()?+?",執(zhí)行方式:"?+?name?+?"】";
????????System.out.println(printStr);
????????throw?new?RuntimeException(printStr?+?",我異常啦!哈哈哈!");
????}
}

這個(gè)程序的輸出結(jié)果是這樣的：

我尋思這沒毛病呀，這不是很正常嗎？不就是應(yīng)該這樣輸出嗎？

那個(gè)哥們說：和你說的不一樣啊，你說的是調(diào)用 future.get 方法的時(shí)候會(huì)拋出異常的？我這里并沒有輸出“future.get Exception”，說明 future.get 方法沒有拋出異常。

我回答到：你這不是把會(huì)拋出運(yùn)行時(shí)異常的 sayHi 方法用 try/catch 代碼塊包裹起來了嗎？異常在子線程里面就處理完了，也就不會(huì)封裝到 Future 里面去了。你把 try/catch 代碼塊去掉，異常就會(huì)封裝到 Future 里面了。

過了一小會(huì)，他應(yīng)該是實(shí)驗(yàn)完了，又找過來了。

他說：牛逼呀，確實(shí)是這樣的。那你的這個(gè)面試題是有問題的啊，描述不清楚，正確的描述應(yīng)該是一個(gè)線程池中的線程拋出了未經(jīng)捕獲的運(yùn)行時(shí)異常，那么線程池會(huì)怎么處理這個(gè)線程？

看到他的這個(gè)回復(fù)的時(shí)候，我竟然鼓起掌來，這屆讀者真是太嚴(yán)格了！但是他說的確實(shí)是沒有錯(cuò)，嚴(yán)謹(jǐn)點(diǎn)好。

他還追問到：怎么實(shí)現(xiàn)的呢？為什么當(dāng) submit 方法提交任務(wù)的時(shí)候，子線程捕獲了異常，future.get 方法就不拋出異常了呢？

其實(shí)聽到這個(gè)問題的時(shí)候都把我干懵了。

這問法，難道你是想再拋一次異常出來？

其實(shí)大家按照正常的思維去想，都能知道如果子線程捕獲了一次，future.get 方法就不應(yīng)該拋出異常了。

所以，現(xiàn)在的問題是，這個(gè)小小的功能，在線程池里面是怎么實(shí)現(xiàn)的？

現(xiàn)在的面試題在原來的基礎(chǔ)上再加一層：

好，你說當(dāng)執(zhí)行方法是 submit 的時(shí)候，如果子線程拋出未經(jīng)捕獲的運(yùn)行時(shí)異常，將會(huì)被封裝到 Future 里面？那么如果子線程捕獲了異常，該異常還會(huì)封裝到 Future 里面嗎？是怎么實(shí)現(xiàn)的呢

尋找答案-FUTURE

來，一起去源碼里面尋找答案。

現(xiàn)在是用 submit 的方式往線程池里面提交任務(wù)，而執(zhí)行的這個(gè)任務(wù)會(huì)拋出運(yùn)行時(shí)異常。

對(duì)于拋出的這個(gè)異常，我們分為兩種情況：

• 子線程中捕獲了異常，則調(diào)用返回的 future 的 get 方法，不會(huì)拋出異常。

• 子線程中沒有捕獲異常，則調(diào)用返回的 future 的 get 方法，會(huì)拋出異常。

兩種情況都和 future.get 方法有關(guān)，那我們就從這個(gè)方法的源碼入手。

這個(gè) Future 是一個(gè)接口：

而這個(gè)接口有非常多的實(shí)現(xiàn)類。我們找哪個(gè)實(shí)現(xiàn)類呢？

就是下面這個(gè)實(shí)現(xiàn)類：

java.util.concurrent.FutureTask

至于是怎么找到它的，你慢慢往后看就知道了。

先看看 FutureTask 的 get 方法：

get 方法的邏輯很簡單，首先判斷當(dāng)前狀態(tài)是否已完成，如果不是，則進(jìn)入等待，如果是，則進(jìn)入 report 方法。

一進(jìn) get 方法，我們就看到了 state 這個(gè)東西，這是 FutureTask 里面一個(gè)非常重要的東西：

在 FutureTask ?里面，一共有 7 種狀態(tài)。這 7 種狀態(tài)之間的流轉(zhuǎn)關(guān)系已經(jīng)在注釋里面寫清楚了。

狀態(tài)之間只會(huì)按照這四個(gè)流程去流轉(zhuǎn)。

所以，一目了然，一個(gè)任務(wù)的終態(tài)有四種：NORMAL、EXCEPTIONAL、CANCELLED、INTERRUPTED。

而我們主要關(guān)心 NORMAL、EXCEPTIONAL。

所以再回頭看看 get 方法：

如果當(dāng)前狀態(tài)是小于 COMPLEING 的。

也就是當(dāng)前狀態(tài)只能是 NEW 或者 COMPLEING，總之就是任務(wù)還沒有完成。所以進(jìn)入 awaitDone 方法。這個(gè)方法不是本文關(guān)心的地方，接著往下看。

程序能往下走，說明當(dāng)前的狀態(tài)肯定是下面圈起來的狀態(tài)中的某一個(gè)：

記住這幾種狀態(tài)，然后看這個(gè) report 方法：

這個(gè)方法是干啥的？

注解說的很清楚了：對(duì)于已經(jīng)完成了的 task，返回其結(jié)果或者拋出異常。

這里面的邏輯就很簡單了，把 outcome 變量賦值給 x 。

然后判斷當(dāng)前狀態(tài)，如果是 NORMAL，即 2，說明正常完成，直接返回 x。

如果是大于等于 CANCELLED，即大于等于 4 ，即這幾種狀態(tài)，就拋出 CancellationException。

剩下的情況就拋出 ExecutionException。

而這個(gè)“剩下的情況”是什么情況？

不就只剩下一個(gè) EXCEPTIONAL 的情況了。

所以，經(jīng)過前面的描述，我們可以總結(jié)一下。

當(dāng) FutureTask 的 status 為 NORMAL 時(shí)正常返回結(jié)果，當(dāng) status 為 EXCEPTIONAL 時(shí)拋出異常。

而當(dāng)終態(tài)為 NORMAL 或者 EXCEPTIONAL 時(shí)，按照注釋描述，狀態(tài)的流程只能是這樣的：

那么到底是不是這樣的呢？

這就需要我們?nèi)ゾ€程池里面驗(yàn)證一下了。

尋找答案-線程池

先回答上一節(jié)的一個(gè)問題：我怎么知道是看 Future 這個(gè)接口的 FutureTask 這個(gè)實(shí)現(xiàn)類的：

submit 方法提交的時(shí)候把任務(wù)包裹了一層，就是用 FutureTask 包裹的：

可以看到，F(xiàn)utureTask 的構(gòu)造方法里面默認(rèn)了狀態(tài)為 NEW。

然后直接在 runWorker 方法的 task.run 方法處打上斷點(diǎn)：

這個(gè) task 是一個(gè) FutureTask，所以 run 方法其實(shí)是 FutureTask 的 run 方法。

跟著斷點(diǎn)進(jìn)去之后，就是 FutureTask 的 run 方法：

答案都藏在這個(gè)方法里面。

java.util.concurrent.FutureTask#run

標(biāo)號(hào)為 ① 的地方是執(zhí)行我們的任務(wù)，call 的就是示例代碼里面的 sayHi 方法。

如果提交的任務(wù)（ sayHi 方法）拋出的運(yùn)行時(shí)異常沒有被捕獲，則會(huì)在標(biāo)號(hào)為 ② 的這個(gè) catch 里面被捕獲。然后執(zhí)行標(biāo)號(hào)為 ② 的這個(gè)代碼。

如果提交的任務(wù)（?sayHi 方法）捕獲了運(yùn)行時(shí)異常，則會(huì)進(jìn)入標(biāo)號(hào)為 ③ 的這個(gè)邏輯里面。

我們分別看一下標(biāo)號(hào)為 ② 和 ③ 的邏輯：

首先，兩個(gè)方法都是先進(jìn)行一個(gè) cas 的操作，把當(dāng)前 FutureTask 的 status 字段從 NEW 修改為 COMPLETING 。

完成了狀態(tài)流轉(zhuǎn)的這一步：

注意這里，如果 cas 操作失敗了，則不會(huì)進(jìn)行任何操作。

cas 操作失敗了，說明什么呢？

說明當(dāng)前的狀態(tài)是 CANCELLED 或者 INTERRUPTING 或者 INTERRUPTED。

也就是這個(gè)任務(wù)被取消了或者被中斷了。

那還設(shè)置結(jié)果干啥，沒有任何卵用，對(duì)不對(duì)。

如果 cas 操作成功，接著往下看，可以看到雖然入?yún)⒉灰粯恿耍嵌假x給了 outcome 變量，這個(gè)變量，在上一節(jié)的 report 方法出現(xiàn)過，還記得嗎？能不能呼應(yīng)上？

接下來就是狀態(tài)接著往下流轉(zhuǎn)。

set 方法表示正常結(jié)束，狀態(tài)流轉(zhuǎn)到 NORMAL。

setException 方法表示任務(wù)出現(xiàn)異常，狀態(tài)流轉(zhuǎn)到 EXCEPTIONAL。

所以經(jīng)過 FutureTask 的 run 方法后，如果任務(wù)沒有被中斷或者取消，則會(huì)通過 setException 或者 set 方法完成狀態(tài)的流轉(zhuǎn)和 outcome 參數(shù)的設(shè)置：

而到底是調(diào)用 setException 方法還是 set 方法，取決于標(biāo)號(hào)為 ① 的地方是否會(huì)拋出異常。

即取決于任務(wù)體是否會(huì)拋出異常。

假設(shè) sayHi 方法是這樣的，會(huì)拋出運(yùn)行時(shí)異常：

而通過 submit 方法提交任務(wù)時(shí)寫法分別如下：

如果是標(biāo)號(hào)為 ① 的寫法，則會(huì)進(jìn)入 setException 方法。

如果是標(biāo)號(hào)為 ② 的寫法，則會(huì)進(jìn)入 set 方法。

所以，你現(xiàn)在再回去看看這個(gè)題目：

當(dāng)執(zhí)行方法是 submit 的時(shí)候，如果子線程拋出未經(jīng)捕獲的運(yùn)行時(shí)異常，將會(huì)被封裝到 Future 里面，那么如果子線程捕獲了異常，該異常還會(huì)封裝到 Future 里面嗎？是怎么實(shí)現(xiàn)的呢？

現(xiàn)在是不是很清晰了。

如果子線程捕獲了異常，該異常不會(huì)被封裝到 Future 里面。是通過 FutureTask 的 run 方法里面的 setException 和 set 方法實(shí)現(xiàn)的。在這兩個(gè)方法里面完成了 FutureTask 里面的 outcome 變量的設(shè)置，同時(shí)完成了從 NEW 到 NORMAL 或者 EXCEPTIONAL 狀態(tài)的流轉(zhuǎn)。

線程池拒絕異常

寫文章的時(shí)候我突然又想到一個(gè)問題。

不論是用 submit 還是 execute 方法往線程池里面提交任務(wù)，如果由于線程池滿了，導(dǎo)致拋出拒絕異常呢？

RejectedExecutionException 異常也是一個(gè) RuntimeException：

那么對(duì)于這個(gè)異常，如果我們不進(jìn)行捕獲，是不是也不會(huì)打印呢？

假設(shè)你不知道這個(gè)問題，你就分析一下，從會(huì)和不會(huì)中猜一個(gè)唄。

我猜是會(huì)打印的。

因?yàn)榧僭O(shè)讓我來提供一個(gè)這樣的功能，由于線程池飽和了而拒絕了新任務(wù)的提交，我肯定得給使用方一個(gè)提示。告訴他有的任務(wù)由于線程池滿了而沒有提交進(jìn)去。

不然，使用者自己排查到這個(gè)問題后，肯定會(huì)說一聲：這什么傻逼玩意，把異常給吞了？

來，搞個(gè) Demo 驗(yàn)證一下：

我們定義的這個(gè)線程池最大容量是 7 個(gè)任務(wù)。

在循環(huán)體中扔 10 個(gè)比較耗時(shí)的任務(wù)進(jìn)去。有 3 個(gè)任務(wù)它處理不了，那么肯定是會(huì)觸發(fā)拒絕策略的。

你覺得這個(gè)程序運(yùn)行后會(huì)在控制臺(tái)打印異常日志嗎？會(huì)打印幾次呢？

看一下運(yùn)行結(jié)果：

拋出了一次異常，執(zhí)行完成了 7 個(gè)任務(wù)。

我們并沒有捕獲異常，打印堆棧信息的相關(guān)代碼，那么這個(gè)異常是誰打印的？

如果你沒有捕獲異常，JVM 會(huì)幫你調(diào)用這個(gè)方法：

而這個(gè)方法里面，會(huì)輸出錯(cuò)誤堆棧：

所以，當(dāng)我們沒有捕獲異常的時(shí)候，會(huì)在這里打印一次堆棧日志。

而當(dāng)我們捕獲了異常之后，改成這樣：

再次運(yùn)行：

10 個(gè)任務(wù)，三次異常，完成了 7 個(gè)任務(wù)。

也不會(huì)讓 JVM 觸發(fā) dispatchUncaughtException 方法了。

而這個(gè)異常日志的打印和哪種方式提交任務(wù)沒有關(guān)系，不論哪種，只要你沒有捕獲異常，則都會(huì)觸發(fā) dispatchUncaughtException?方法。

終極答案

上面說這個(gè)例子，其實(shí)我就是想引出終極答案。

終極答案就是：dispatchUncaughtException 方法。

為什么這樣說呢？

我們現(xiàn)在把情況分為三種。

第一種：submit 方法提交一個(gè)會(huì)拋出運(yùn)行時(shí)異常的任務(wù)，捕不捕獲異常都可以。

第二種：execute 方法提交一個(gè)會(huì)拋出運(yùn)行時(shí)異常的任務(wù)，不捕獲異常。

第三種：submit 或者 execute 提交，讓線程池飽和之后拋出拒絕異常，代碼沒有捕獲異常。

第一種情況，無論如何都不會(huì)觸發(fā) dispatchUncaughtException 方法。因?yàn)?submit 方法提交，不論你捕獲與否，源碼里面都幫你捕獲了：

第二種情況，如果不捕獲異常，會(huì)觸發(fā) dispatchUncaughtException 方法，因?yàn)?runWorker 方法的源碼里面雖然捕獲了異常，但是又拋出去了：

而我們自己沒有捕獲，所以會(huì)觸發(fā) dispatchUncaughtException 方法。

第三種情況，和第二種其實(shí)是一樣的。沒有捕獲，就會(huì)觸發(fā)。

那么我現(xiàn)在給你一段這樣的代碼：

你肯定知道這是會(huì)拋出異常的吧。

就像這樣式兒的：

我們完全沒有打印日志的代碼吧？

那你現(xiàn)在知道控制臺(tái)這個(gè)異常信息是怎么來的了不？

是不是平時(shí)根本就沒有注意這個(gè)點(diǎn)。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝