Java線程的異常處理機(jī)制詳情

更新時(shí)間：2022年07月03日 09:13:33 作者：??yogurtzzz????

這篇文章主要介紹了Java線程的異常處理機(jī)制詳情，文章圍繞主題展開詳細(xì)的內(nèi)容介紹，具有一定的參考價(jià)值，需要的小伙伴可以參考一下

前言

啟動(dòng)一個(gè)Java程序，本質(zhì)上是運(yùn)行某個(gè)Java類的main方法。我們寫一個(gè)死循環(huán)程序，跑起來，然后運(yùn)行jvisualvm進(jìn)行觀察

可以看到這個(gè)Java進(jìn)程中，一共有11個(gè)線程，其中10個(gè)守護(hù)線程，1個(gè)用戶線程。我們main方法中的代碼，就跑在一個(gè)名為main的線程中。當(dāng)Java進(jìn)程中跑著的所有線程都是守護(hù)線程時(shí)，JVM就會(huì)退出。

在單線程的場(chǎng)景下，如果代碼運(yùn)行到某個(gè)位置時(shí)拋出了異常，會(huì)看到控制臺(tái)打印出異常的堆棧信息。但在多線程的場(chǎng)景下，子線程中發(fā)生的異常，不一定就能及時(shí)的將異常信息打印出來。

我曾經(jīng)在工作中遇到過一次，采用CompletableFuture.runAsync異步處理耗時(shí)任務(wù)時(shí)，任務(wù)處理過程中出現(xiàn)異常，然而日志中沒有任何關(guān)于異常的信息。時(shí)隔許久，重新溫習(xí)了線程中的異常處理機(jī)制，加深了對(duì)線程工作原理的理解，特此記錄。

線程的異常處理機(jī)制

我們知道，Java程序的運(yùn)行，是先經(jīng)由javac將Java源代碼編譯成class字節(jié)碼文件，然后由JVM加載并解析class文件，隨后從主類的main方法開始執(zhí)行。當(dāng)一個(gè)線程在運(yùn)行過程中拋出了未捕獲異常時(shí)，會(huì)由JVM調(diào)用這個(gè)線程對(duì)象上的dispatchUncaughtException方法，進(jìn)行異常處理。

// Thread類中
private void dispatchUncaughtException(Throwable e) {
        getUncaughtExceptionHandler().uncaughtException(this, e);
}

源碼很好理解，先獲取一個(gè)UncaughtExceptionHandler異常處理器，然后通過調(diào)用這個(gè)異常處理器的uncaughtException方法來對(duì)異常進(jìn)行處理。（下文用縮寫ueh來表示UncaughtExceptionHandler）

ueh是個(gè) 啥呢？其實(shí)就是定義在Thread內(nèi)部的一個(gè)接口，用作異常處理。

    @FunctionalInterface
    public interface UncaughtExceptionHandler {
        /**
         * Method invoked when the given thread terminates due to the
         * given uncaught exception.
         * <p>Any exception thrown by this method will be ignored by the
         * Java Virtual Machine.
         * @param t the thread
         * @param e the exception
         */
        void uncaughtException(Thread t, Throwable e);
    }

再來看下Thread對(duì)象中的getUncaughtExceptionHandler方法

	public UncaughtExceptionHandler getUncaughtExceptionHandler() {
        return uncaughtExceptionHandler != null ?
            uncaughtExceptionHandler : group;
    }

先查看當(dāng)前這個(gè)Thread對(duì)象是否有設(shè)置自定義的ueh對(duì)象，若有，則由其對(duì)異常進(jìn)行處理，否則，由當(dāng)前Thread對(duì)象所屬的線程組（ThreadGroup）進(jìn)行異常處理。我們點(diǎn)開源碼，容易發(fā)現(xiàn)ThreadGroup類本身實(shí)現(xiàn)了Thread.UncaughtExceptionHandler接口，也就是說ThreadGroup本身就是個(gè)異常處理器。

public class ThreadGroup implements Thread.UncaughtExceptionHandler {
    private final ThreadGroup parent;
    ....
}

假設(shè)我們?cè)?code>main方法中拋出一個(gè)異常，若沒有對(duì)main線程設(shè)置自定義的ueh對(duì)象，則交由main線程所屬的ThreadGroup來處理異常。我們看下ThreadGroup是怎么處理異常的：

    public void uncaughtException(Thread t, Throwable e) {
        if (parent != null) {
            parent.uncaughtException(t, e);
        } else {
            Thread.UncaughtExceptionHandler ueh =
                Thread.getDefaultUncaughtExceptionHandler();
            if (ueh != null) {
                ueh.uncaughtException(t, e);
            } else if (!(e instanceof ThreadDeath)) {
                System.err.print("Exception in thread \""
                                 + t.getName() + "\" ");
                e.printStackTrace(System.err);
            }
        }
    }

這部分源碼也比較簡(jiǎn)短。首先是查看當(dāng)前ThreadGroup是否擁有父級(jí)的ThreadGroup，若有，則調(diào)用父級(jí)ThreadGroup進(jìn)行異常處理。否則，調(diào)用靜態(tài)方法Thread.getDefaultUncaughtExceptionHandler()獲取一個(gè)默認(rèn)的ueh對(duì)象。

若默認(rèn)的ueh對(duì)象不為空，則由這個(gè)默認(rèn)的ueh對(duì)象進(jìn)行異常處理；否則，當(dāng)異常不是ThreadDeath時(shí)，直接將當(dāng)前線程的名字，和異常的堆棧信息，通過標(biāo)準(zhǔn)錯(cuò)誤輸出（System.err）打印到控制臺(tái)。

我們隨便運(yùn)行一個(gè)main方法，看一下線程的情況

可以看到，main線程屬于一個(gè)同樣名為main的ThreadGroup，而這個(gè)main的ThreadGroup，其父級(jí)ThreadGroup名為system，而這個(gè)system的ThreadGroup，沒有父級(jí)了，它就是根ThreadGroup。

由此可知，main線程中拋出的未捕獲異常，最終會(huì)交由名為system的ThreadGroup進(jìn)行異常處理，而由于沒有設(shè)置默認(rèn)的ueh對(duì)象，異常信息會(huì)通過System.err輸出到控制臺(tái)。

接下來，我們通過最樸素的方式（new一個(gè)Thread），在main線程中創(chuàng)建一個(gè)子線程，在子線程中編寫能拋出異常的代碼，進(jìn)行觀察

    public static void main(String[] args)  {
        Thread thread = new Thread(() -> {
            System.out.println(3 / 0);
        });
        thread.start();
    }

子線程中的異常信息被打印到了控制臺(tái)。異常處理的流程就是我們上面描述的那樣。

小結(jié)

所以，正常來說，如果沒有對(duì)某個(gè)線程設(shè)置特定的ueh對(duì)象；也沒有調(diào)用靜態(tài)方法Thread.setDefaultUncaughtExceptionHandler設(shè)置全局默認(rèn)的ueh對(duì)象。那么，在任意一個(gè)線程的運(yùn)行過程中拋出未捕獲異常時(shí)，異常信息都會(huì)被輸出到控制臺(tái)（當(dāng)異常是ThreadDeath時(shí)則不會(huì)進(jìn)行輸出，但通常來說，異常都不是ThreadDeath，不過這個(gè)細(xì)節(jié)要注意下）。

如何設(shè)置自定義的ueh對(duì)象來進(jìn)行異常處理？根據(jù)上面的分析可知，有2種方式

對(duì)某一個(gè)Thread對(duì)象，調(diào)用其setUncaughtExceptionHandler方法，設(shè)置一個(gè)ueh對(duì)象。注意這個(gè)ueh對(duì)象只對(duì)這個(gè)線程起作用
調(diào)用靜態(tài)方法Thread.setDefaultUncaughtExceptionHandler()設(shè)置一個(gè)全局默認(rèn)的ueh對(duì)象。這樣設(shè)置的ueh對(duì)象會(huì)對(duì)所有線程起作用

當(dāng)然，由于ThreadGroup本身可以充當(dāng)ueh，所以其實(shí)還可以實(shí)現(xiàn)一個(gè)ThreadGroup子類，重寫其uncaughtException方法進(jìn)行異常處理。

若一個(gè)線程沒有進(jìn)行任何設(shè)置，當(dāng)在這個(gè)線程內(nèi)拋出異常后，默認(rèn)會(huì)將線程名稱和異常堆棧，通過System.err進(jìn)行輸出。

線程的異常處理機(jī)制，用一個(gè)流程圖表示如下：

線程池場(chǎng)景下的異常處理

在實(shí)際的開發(fā)中，我們經(jīng)常會(huì)使用線程池來進(jìn)行多線程的管理和控制，而不是通過new來手動(dòng)創(chuàng)建Thread對(duì)象。

對(duì)于Java中的線程池ThreadPoolExecutor，我們知道，通常來說有兩種方式，可以向線程池提交任務(wù)：

execute
submit

其中execute方法沒有返回值，我們通過execute提交的任務(wù)，只需要提交該任務(wù)給線程池執(zhí)行，而不需要獲取任務(wù)的執(zhí)行結(jié)果。而submit方法，會(huì)返回一個(gè)Future對(duì)象，我們通過submit提交的任務(wù)，可以通過這個(gè)Future對(duì)象，拿到任務(wù)的執(zhí)行結(jié)果。

我們分別嘗試如下代碼：

    public static void main(String[] args)  {
        ExecutorService threadPool = Executors.newSingleThreadExecutor();
        threadPool.execute(() -> {
            System.out.println(3 / 0);
        });
    }

    public static void main(String[] args)  {
        ExecutorService threadPool = Executors.newSingleThreadExecutor();
        threadPool.submit(() -> {
            System.out.println(3 / 0);
        });
    }

容易得到如下結(jié)果：

通過execute方法提交的任務(wù)，異常信息被打印到控制臺(tái)；通過submit方法提交的任務(wù)，沒有出現(xiàn)異常信息。

我們稍微跟一下ThreadPoolExecutor的源碼，當(dāng)使用execute方法提交任務(wù)時(shí)，在runWorker方法中，會(huì)執(zhí)行到下圖紅框的部分

在上面的代碼執(zhí)行完畢后，由于異常被throw了出來，所以會(huì)由JVM捕捉到，并調(diào)用當(dāng)前子線程的dispatchUncaughtException方法進(jìn)行處理，根據(jù)上面的分析，最終異常堆棧會(huì)被打印到控制臺(tái)。

多扯幾句別的。

上面跟源碼時(shí)，注意到Worker是ThreadPoolExecutor的一個(gè)內(nèi)部類，也就是說，每個(gè)Worker都會(huì)隱式的持有ThreadPoolExecutor對(duì)象的引用（內(nèi)部類的相關(guān)原理請(qǐng)自行補(bǔ)課）。每個(gè)Worker在運(yùn)行時(shí)（在不同的子線程中運(yùn)行）都能夠?qū)?code>ThreadPoolExecutor對(duì)象（通常來說這個(gè)對(duì)象是在main線程中被維護(hù)）中的屬性進(jìn)行訪問和修改。Worker實(shí)現(xiàn)了Runnable接口，并且其run方法實(shí)際是調(diào)用的ThreadPoolExecutor上的runWorker方法。在新建一個(gè)Worker時(shí)，會(huì)創(chuàng)建一個(gè)新的Thread對(duì)象，并把當(dāng)前Worker的引用傳遞給這個(gè)Thread對(duì)象，隨后調(diào)用這個(gè)Thread對(duì)象的start方法，則開始在這個(gè)Thread中（子線程中）運(yùn)行這個(gè)Worker。

        Worker(Runnable firstTask) {
            setState(-1); // inhibit interrupts until runWorker
            this.firstTask = firstTask;
            this.thread = getThreadFactory().newThread(this);
        }

ThreadPoolExecutor中的addWorker方法

再次跟源碼時(shí)，加深了對(duì)ThreadPoolExecutor和Worker體系的理解和認(rèn)識(shí)。

它們之間有一種嵌套依賴的關(guān)系。每個(gè)Worker里持有一個(gè)Thread對(duì)象，這個(gè)Thread對(duì)象又是以這個(gè)Worker對(duì)象作為Runnable，而Worker又是ThreadPoolExecutor的內(nèi)部類，這意味著每個(gè)Worker對(duì)象都會(huì)隱式的持有其所屬的ThreadPoolExecutor對(duì)象的引用。每個(gè)Worker的run方法，都跑在子線程中，但是這些Worker跑在子線程中時(shí)，能夠?qū)?code>ThreadPoolExecutor對(duì)象的屬性進(jìn)行訪問和修改（每個(gè)Worker的run方法都是調(diào)用的runWorker，所以runWorker方法是跑在子線程中的，這個(gè)方法中會(huì)對(duì)線程池的狀態(tài)進(jìn)行訪問和修改，比如當(dāng)前子線程運(yùn)行過程中拋出異常時(shí)，會(huì)從ThreadPoolExecutor中移除當(dāng)前Worker，并啟一個(gè)新的Worker）。而通常來說，ThreadPoolExecutor對(duì)象的引用，我們通常是在主線程中進(jìn)行維護(hù)的。

反正就是這中間其實(shí)有點(diǎn)騷東西，沒那么簡(jiǎn)單。需要多跟幾次源碼，多自己打斷點(diǎn)進(jìn)行debug，debug過程中可以通過IDEA的Evaluate Expression功能實(shí)時(shí)觀察當(dāng)前方法執(zhí)行時(shí)所處的線程環(huán)境（Thread.currentThread）。

扯得有點(diǎn)遠(yuǎn)了，現(xiàn)在回到正題。上面說了調(diào)用ThreadPoolExecutor中的execute方法提交任務(wù)，子線程中出現(xiàn)異常時(shí)，異常會(huì)被拋出，打印在控制臺(tái)，并且當(dāng)前Worker會(huì)被線程池回收，并重啟一個(gè)新的Worker作為替代。那么，調(diào)用submit時(shí)，異常為何就沒有被打印到控制臺(tái)呢？

我們看一下源碼：

    public Future<?> submit(Runnable task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<Void> ftask = newTaskFor(task, null);
        execute(ftask);
        return ftask;
    }

    protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
        return new FutureTask<T>(runnable, value);
    }

通過調(diào)用submit提交的任務(wù)，被包裝了成了一個(gè)FutureTask對(duì)象，隨后會(huì)將這個(gè)FutureTask對(duì)象，通過execute方法提交給線程池，并返回FutureTask對(duì)象給主線程的調(diào)用者。

也就是說，submit方法實(shí)際做了這幾件事

將提交的Runnable，包裝成FutureTask
調(diào)用execute方法提交這個(gè)FutureTask（實(shí)際還是通過execute提交的任務(wù)）
將FutureTask作為返回值，返回給主線程的調(diào)用者

關(guān)鍵就在于FutureTask，我們來看一下

    public FutureTask(Runnable runnable, V result) {
        this.callable = Executors.callable(runnable, result);
        this.state = NEW;       // ensure visibility of callable
    }

    // Executors中
	public static <T> Callable<T> callable(Runnable task, T result) {
        if (task == null)
            throw new NullPointerException();
        return new RunnableAdapter<T>(task, result);
    }

    static final class RunnableAdapter<T> implements Callable<T> {
        final Runnable task;
        final T result;
        RunnableAdapter(Runnable task, T result) {
            this.task = task;
            this.result = result;
        }
        public T call() {
            task.run();
            return result;
        }
    }

通過submit方法傳入的Runnable，通過一個(gè)適配器RunnableAdapter轉(zhuǎn)化為了Callable對(duì)象，并最終包裝成為一個(gè)FutureTask對(duì)象。這個(gè)FutureTask，又實(shí)現(xiàn)了Runnable和Future接口

于是我們看下FutureTask的run方法（因?yàn)樽罱K是將包裝后的FutureTask提交給線程池執(zhí)行，所以最終會(huì)執(zhí)行FutureTask的run方法）

    protected void setException(Throwable t) {
        if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
            outcome = t;
            UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state
            finishCompletion();
        }
    }

可以看到，異常信息只是被簡(jiǎn)單的設(shè)置到了FutureTask的outcome字段上。并沒有往外拋，所以這里其實(shí)相當(dāng)于把異常給生吞了，catch塊中捕捉到異常后，既沒有打印異常的堆棧，也沒有把異常繼續(xù)往外throw。所以我們無法在控制臺(tái)看到異常信息，在實(shí)際的項(xiàng)目中，此種場(chǎng)景下的異常信息也不會(huì)被輸出到日志文件。這一點(diǎn)要特別注意，會(huì)加大問題的排查難度。

那么，為什么要這樣處理呢？

因?yàn)槲覀兺ㄟ^submit提交任務(wù)時(shí)，會(huì)拿到一個(gè)Future對(duì)象

    public Future<?> submit(Runnable task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<Void> ftask = newTaskFor(task, null);
        execute(ftask);
        return ftask;
    }

我們可以在稍后，通過Future對(duì)象，來獲知任務(wù)的執(zhí)行情況，包括任務(wù)是否成功執(zhí)行完畢，任務(wù)執(zhí)行后返回的結(jié)果是什么，執(zhí)行過程中是否出現(xiàn)異常。

所以，通過submit提交的任務(wù)，實(shí)際會(huì)把任務(wù)的各種狀態(tài)信息，都封裝在FutureTask對(duì)象中。當(dāng)最后調(diào)用FutureTask對(duì)象上的get方法，嘗試獲取任務(wù)執(zhí)行結(jié)果時(shí)，才能夠看到異常信息被打印出來。

    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }

    private V report(int s) throws ExecutionException {
        Object x = outcome;
        if (s == NORMAL)
            return (V)x;
        if (s >= CANCELLED)
            throw new CancellationException();
        throw new ExecutionException((Throwable)x); // 異常會(huì)通過這一句被拋出來
    }

小結(jié)

通過ThreadPoolExecutor的execute方法提交的任務(wù)，出現(xiàn)異常后，異常會(huì)在子線程中被拋出，并被JVM捕獲，并調(diào)用子線程的dispatchUncaughtException方法，進(jìn)行異常處理，若子線程沒有任何特殊設(shè)置，則異常堆棧會(huì)被輸出到System.err，即異常會(huì)被打印到控制臺(tái)上。并且會(huì)從線程池中移除當(dāng)前Worker，并另啟一個(gè)新的Worker作為替代。
通過ThreadPoolExecutor的submit方法提交的任務(wù)，任務(wù)會(huì)先被包裝成FutureTask對(duì)象，出現(xiàn)異常后，異常會(huì)被生吞，并暫存到FutureTask對(duì)象中，作為任務(wù)執(zhí)行結(jié)果的一部分。異常信息不會(huì)被打印，該子線程也不會(huì)被線程池移除（因?yàn)楫惓Ｔ谧泳€程中被吞了，沒有拋出來）。在調(diào)用FutureTask上的get方法時(shí)（此時(shí)一般是在主線程中了），異常才會(huì)被拋出，觸發(fā)主線程的異常處理，并輸出到System.err

其他

其他的線程池場(chǎng)景

比如：

使用ScheduledThreadPoolExecutor實(shí)現(xiàn)延遲任務(wù)或者定時(shí)任務(wù)（周期任務(wù)），分析過程也是類似。這里給個(gè)簡(jiǎn)單結(jié)論，當(dāng)調(diào)用scheduleAtFixedRate方法執(zhí)行一個(gè)周期任務(wù)時(shí)（任務(wù)會(huì)被包裝成FutureTask （實(shí)際是ScheduledFutureTask ，是FutureTask 的子類）），若周期任務(wù)中出現(xiàn)異常，異常會(huì)被生吞，異常信息不會(huì)被打印，線程不會(huì)被回收，但是周期任務(wù)執(zhí)行這一次后就不會(huì)繼續(xù)執(zhí)行了。ScheduledThreadPoolExecutor繼承了ThreadPoolExecutor，所以其也是復(fù)用了ThreadPoolExecutor的那一套邏輯。
使用CompletableFuture 的runAsync 提交任務(wù)，底層是通過ForkJoinPool 線程池進(jìn)行執(zhí)行，任務(wù)會(huì)被包裝成AsyncRun ，且會(huì)返回一個(gè)CompletableFuture 給主線程。當(dāng)任務(wù)出現(xiàn)異常時(shí)，處理方式和ThreadPoolExecutor 的submit 類似，異常堆棧不會(huì)被打印。只有在CompletableFuture 上調(diào)用get 方法嘗試獲取結(jié)果時(shí)，異常才會(huì)被打印。