Java線程的異常處理機制詳情

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

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

前言

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

可以看到這個Java進程中，一共有11個線程，其中10個守護線程，1個用戶線程。我們main方法中的代碼，就跑在一個名為main的線程中。當Java進程中跑著的所有線程都是守護線程時，JVM就會退出。

在單線程的場景下，如果代碼運行到某個位置時拋出了異常，會看到控制臺打印出異常的堆棧信息。但在多線程的場景下，子線程中發(fā)生的異常，不一定就能及時的將異常信息打印出來。

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

線程的異常處理機制

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

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

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

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

    @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對象中的getUncaughtExceptionHandler方法

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

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

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

假設(shè)我們在main方法中拋出一個異常，若沒有對main線程設(shè)置自定義的ueh對象，則交由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);
            }
        }
    }

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

若默認的ueh對象不為空，則由這個默認的ueh對象進行異常處理；否則，當異常不是ThreadDeath時，直接將當前線程的名字，和異常的堆棧信息，通過標準錯誤輸出（System.err）打印到控制臺。

我們隨便運行一個main方法，看一下線程的情況

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

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

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

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

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

小結(jié)

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

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

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

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

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

線程的異常處理機制，用一個流程圖表示如下：

線程池場景下的異常處理

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

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

execute
submit

其中execute方法沒有返回值，我們通過execute提交的任務(wù)，只需要提交該任務(wù)給線程池執(zhí)行，而不需要獲取任務(wù)的執(zhí)行結(jié)果。而submit方法，會返回一個Future對象，我們通過submit提交的任務(wù)，可以通過這個Future對象，拿到任務(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ù)，異常信息被打印到控制臺；通過submit方法提交的任務(wù)，沒有出現(xiàn)異常信息。

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

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

多扯幾句別的。

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

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

ThreadPoolExecutor中的addWorker方法

再次跟源碼時，加深了對ThreadPoolExecutor和Worker體系的理解和認識。

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

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

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

我們看一下源碼：

    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ù)，被包裝了成了一個FutureTask對象，隨后會將這個FutureTask對象，通過execute方法提交給線程池，并返回FutureTask對象給主線程的調(diào)用者。

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

將提交的Runnable，包裝成FutureTask
調(diào)用execute方法提交這個FutureTask（實際還是通過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，通過一個適配器RunnableAdapter轉(zhuǎn)化為了Callable對象，并最終包裝成為一個FutureTask對象。這個FutureTask，又實現(xiàn)了Runnable和Future接口

于是我們看下FutureTask的run方法（因為最終是將包裝后的FutureTask提交給線程池執(zhí)行，所以最終會執(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();
        }
    }

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

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

因為我們通過submit提交任務(wù)時，會拿到一個Future對象

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

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

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

    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); // 異常會通過這一句被拋出來
    }

小結(jié)

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

其他

其他的線程池場景

比如：

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