關於多執行緒中拋異常的這個面試題我再說最後一次！

why技術發表於2020-09-21

執行緒面試題

這裡why的第 66 篇原創文章

一道面試題

我一年前寫過這篇文章《有的執行緒它死了，於是它變成一道面試題》，這是早期作品，遣詞造句，排版行文都有一點稚嫩，但是不知咋地，還是有很多人看過。

甚至已經進入了某網紅公司的面試題庫裡面。

所以我後面應該會重寫一下，翻新翻新，再補充一點新的東西進去。

現在先回顧一下這篇文章丟擲的問題和問題的答案：

一個執行緒池中的執行緒異常了，那麼執行緒池會怎麼處理這個執行緒?

這個題是我遇到的一個真實的面試題，當時並沒有回答的很好。然後通過上面的文章，我在原始碼中尋找到了答案。

先給大家看兩個案例。

當執行方式是 execute 方法時，在控制檯會列印堆疊異常：

當執行方式是 submit 方法時，在控制檯不會列印堆疊異常：

那麼怎麼獲取這個 submit 方法提交時的異常資訊呢？

得呼叫返回值 future 的 get 方法：

具體原因，我在之前的文章裡面詳細分析過，就不贅述了，直接看結論：

然後一個讀者找我聊天，說為什麼他這樣寫，通過 future.get 方法沒有丟擲異常呢，和我文章裡面說的不一樣呢？

我說：那肯定是你操作不對，你把程式碼發給我看看。

然後我收到了一份這樣的程式碼：

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() + ",執行方式:" + name + "】";
        System.out.println(printStr);
        throw new RuntimeException(printStr + ",我異常啦!哈哈哈!");
    }
}

這個程式的輸出結果是這樣的：

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

那個哥們說：和你說的不一樣啊，你說的是呼叫 future.get 方法的時候會丟擲異常的？我這裡並沒有輸出“future.get Exception”，說明 future.get 方法沒有丟擲異常。

我回答到：你這不是把會丟擲執行時異常的 sayHi 方法用 try/catch 程式碼塊包裹起來了嗎？異常在子執行緒裡面就處理完了，也就不會封裝到 Future 裡面去了。你把 try/catch 程式碼塊去掉，異常就會封裝到 Future 裡面了。

過了一小會，他應該是實驗完了，又找過來了。

他說：牛逼呀，確實是這樣的。那你的這個面試題是有問題的啊，描述不清楚，正確的描述應該是一個執行緒池中的執行緒丟擲了未經捕獲的執行時異常，那麼執行緒池會怎麼處理這個執行緒？

看到他的這個回覆的時候，我竟然鼓起掌來，這屆讀者真是太嚴格了！但是他說的確實是沒有錯，嚴謹點好。

他還追問到：怎麼實現的呢？為什麼當 submit 方法提交任務的時候，子執行緒捕獲了異常，future.get 方法就不丟擲異常了呢？

其實聽到這個問題的時候都把我幹懵了。

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

其實大家按照正常的思維去想，都能知道如果子執行緒捕獲了一次，future.get 方法就不應該丟擲異常了。

所以，現在的問題是，這個小小的功能，線上程池裡面是怎麼實現的？

現在的面試題在原來的基礎上再加一層：

好，你說當執行方法是 submit 的時候，如果子執行緒丟擲未經捕獲的執行時異常，將會被封裝到 Future 裡面？那麼如果子執行緒捕獲了異常，該異常還會封裝到 Future 裡面嗎？是怎麼實現的呢？

尋找答案-FUTURE

來，一起去原始碼裡面尋找答案。

現在是用 submit 的方式往執行緒池裡面提交任務，而執行的這個任務會丟擲執行時異常。

對於丟擲的這個異常，我們分為兩種情況：

子執行緒中捕獲了異常，則呼叫返回的 future 的 get 方法，不會丟擲異常。
子執行緒中沒有捕獲異常，則呼叫返回的 future 的 get 方法，會丟擲異常。

兩種情況都和 future.get 方法有關，那我們就從這個方法的原始碼入手。

這個 Future 是一個介面：

而這個介面有非常多的實現類。我們找哪個實現類呢？

就是下面這個實現類：

java.util.concurrent.FutureTask

至於是怎麼找到它的，你慢慢往後看就知道了。

先看看 FutureTask 的 get 方法：

get 方法的邏輯很簡單，首先判斷當前狀態是否已完成，如果不是，則進入等待，如果是，則進入 report 方法。

一進 get 方法，我們就看到了 state 這個東西，這是 FutureTask 裡面一個非常重要的東西：

在 FutureTask 裡面，一共有 7 種狀態。這 7 種狀態之間的流轉關係已經在註釋裡面寫清楚了。

狀態之間只會按照這四個流程去流轉。

所以，一目瞭然，一個任務的終態有四種：NORMAL、EXCEPTIONAL、CANCELLED、INTERRUPTED。

而我們主要關心 NORMAL、EXCEPTIONAL。

所以再回頭看看 get 方法：

如果當前狀態是小於 COMPLEING 的。

也就是當前狀態只能是 NEW 或者 COMPLEING，總之就是任務還沒有完成。所以進入 awaitDone 方法。這個方法不是本文關心的地方，接著往下看。

程式能往下走，說明當前的狀態肯定是下面圈起來的狀態中的某一個：

記住這幾種狀態，然後看這個 report 方法：

這個方法是幹啥的？

註解說的很清楚了：對於已經完成了的 task，返回其結果或者丟擲異常。

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

然後判斷當前狀態，如果是 NORMAL，即 2，說明正常完成，直接返回 x。

如果是大於等於 CANCELLED，即大於等於 4 ，即這幾種狀態，就丟擲 CancellationException。

剩下的情況就丟擲 ExecutionException。

而這個“剩下的情況”是什麼情況？

不就只剩下一個 EXCEPTIONAL 的情況了。

所以，經過前面的描述，我們可以總結一下。

當 FutureTask 的 status 為 NORMAL 時正常返回結果，當 status 為 EXCEPTIONAL 時丟擲異常。

而當終態為 NORMAL 或者 EXCEPTIONAL 時，按照註釋描述，狀態的流程只能是這樣的：

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

這就需要我們去執行緒池裡面驗證一下了。

尋找答案-執行緒池

先回答上一節的一個問題：我怎麼知道是看 Future 這個介面的 FutureTask 這個實現類的：

submit 方法提交的時候把任務包裹了一層，就是用 FutureTask 包裹的：

可以看到，FutureTask 的構造方法裡面預設了狀態為 NEW。

然後直接在 runWorker 方法的 task.run 方法處打上斷點：

這個 task 是一個 FutureTask，所以 run 方法其實是 FutureTask 的 run 方法。

跟著斷點進去之後，就是 FutureTask 的 run 方法：

答案都藏在這個方法裡面。

java.util.concurrent.FutureTask#run

標號為 ① 的地方是執行我們的任務，call 的就是示例程式碼裡面的 sayHi 方法。

如果 sayHi 方法沒有捕獲執行時異常，則會在標號為 ② 的這個 catch 裡面被捕獲。然後執行標號為 ② 的這個程式碼。

如果 sayHi 方法捕獲了執行時異常，則會進入標號為 ③ 的這個邏輯裡面。

我們分別看一下標號為 ② 和 ③ 的邏輯：

首先，兩個方法都是先進行一個 cas 的操作，把當前 FutureTask 的 status 欄位從 NEW 修改為 COMPLETING 。

完成了狀態流轉的這一步：

注意這裡，如果 cas 操作失敗了，則不會進行任何操作。

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

說明當前的狀態是 CANCELLED 或者 INTERRUPTING 或者INTERRUPTED。

也就是這個任務被取消了或者被中斷了。

那還設定結果乾啥，沒有任何卵用，對不對。

如果 cas 操作成功，接著往下看，可以看到雖然入參不一樣了，但是都賦給了 outcome 變數，這個變數，在上一節的 report 方法出現過，還記得嗎？能不能呼應上？

接下來就是狀態接著往下流轉。

set 方法表示正常結束，狀態流轉到 NORMAL。

setException 方法表示任務出現異常，狀態流轉到 EXCEPTIONAL。

所以經過 FutureTask 的 run 方法後，如果任務沒有被中斷或者取消，則會通過 setException 或者 set 方法完成狀態的流轉和 outcome 引數的設定：

而到底是呼叫 setException 方法還是 set 方法，取決於標號為 ① 的地方是否會丟擲異常。

即取決於任務體是否會丟擲異常。

假設 sayHi 方法是這樣的，會丟擲執行時異常：

而通過 submit 方法提交任務時寫法分別如下：

如果是標號為 ① 的寫法，則會進入 setException 方法。

如果是標號為 ② 的寫法，則會進入 set 方法。

所以，你現在再回去看看這個題目：

當執行方法是 submit 的時候，如果子執行緒丟擲未經捕獲的執行時異常，將會被封裝到 Future 裡面，那麼如果子執行緒捕獲了異常，該異常還會封裝到 Future 裡面嗎？是怎麼實現的呢？

現在是不是很清晰了。

如果子執行緒捕獲了異常，該異常不會被封裝到 Future 裡面。是通過 FutureTask 的 run 方法裡面的 setException 和 set 方法實現的。在這兩個方法裡面完成了 FutureTask 裡面的 outcome 變數的設定，同時完成了從 NEW 到 NORMAL 或者 EXCEPTIONAL 狀態的流轉。