Java線程的異常處理機制是什么

本文小編為大家詳細介紹“Java線程的異常處理機制是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Java線程的異常處理機制是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

前言

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

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

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

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

線程的異常處理機制

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

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

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

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

    @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對象是否有設置自定義的ueh對象，若有，則由其對異常進行處理，否則，由當前Thread對象所屬的線程組（ThreadGroup）進行異常處理。我們點開源碼，容易發現ThreadGroup類本身實現了Thread.UncaughtExceptionHandler接口，也就是說ThreadGroup本身就是個異常處理器。

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

假設我們在main方法中拋出一個異常，若沒有對main線程設置自定義的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，若有，則調用父級ThreadGroup進行異常處理。否則，調用靜態方法Thread.getDefaultUncaughtExceptionHandler()獲取一個默認的ueh對象。

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

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

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

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

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

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

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

小結

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

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

• 對某一個Thread對象，調用其setUncaughtExceptionHandler方法，設置一個ueh對象。注意這個ueh對象只對這個線程起作用

• 調用靜態方法Thread.setDefaultUncaughtExceptionHandler()設置一個全局默認的ueh對象。這樣設置的ueh對象會對所有線程起作用

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

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

線程池場景下的異常處理

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

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

• execute

• submit

其中execute方法沒有返回值，我們通過execute提交的任務，只需要提交該任務給線程池執行，而不需要獲取任務的執行結果。而submit方法，會返回一個Future對象，我們通過submit提交的任務，可以通過這個Future對象，拿到任務的執行結果。

我們分別嘗試如下代碼：

    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);
        });
    }

容易得到如下結果：

通過execute方法提交的任務，異常信息被打印到控制臺；通過submit方法提交的任務，沒有出現異常信息。

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

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

多扯幾句別的。

上面跟源碼時，注意到Worker是ThreadPoolExecutor的一個內部類，也就是說，每個Worker都會隱式的持有ThreadPoolExecutor對象的引用（內部類的相關原理請自行補課）。每個Worker在運行時（在不同的子線程中運行）都能夠對ThreadPoolExecutor對象（通常來說這個對象是在main線程中被維護）中的屬性進行訪問和修改。Worker實現了Runnable接口，并且其run方法實際是調用的ThreadPoolExecutor上的runWorker方法。在新建一個Worker時，會創建一個新的Thread對象，并把當前Worker的引用傳遞給這個Thread對象，隨后調用這個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體系的理解和認識。

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

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

扯得有點遠了，現在回到正題。上面說了調用ThreadPoolExecutor中的execute方法提交任務，子線程中出現異常時，異常會被拋出，打印在控制臺，并且當前Worker會被線程池回收，并重啟一個新的Worker作為替代。那么，調用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);
    }

通過調用submit提交的任務，被包裝了成了一個FutureTask對象，隨后會將這個FutureTask對象，通過execute方法提交給線程池，并返回FutureTask對象給主線程的調用者。

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

• 將提交的Runnable，包裝成FutureTask

• 調用execute方法提交這個FutureTask（實際還是通過execute提交的任務）

• 將FutureTask作為返回值，返回給主線程的調用者

關鍵就在于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轉化為了Callable對象，并最終包裝成為一個FutureTask對象。這個FutureTask，又實現了Runnable和Future接口

于是我們看下FutureTask的run方法（因為最終是將包裝后的FutureTask提交給線程池執行，所以最終會執行FutureTask的run方法）

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

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

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

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

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

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

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

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

小結

• 通過ThreadPoolExecutor的execute方法提交的任務，出現異常后，異常會在子線程中被拋出，并被JVM捕獲，并調用子線程的dispatchUncaughtException方法，進行異常處理，若子線程沒有任何特殊設置，則異常堆棧會被輸出到System.err，即異常會被打印到控制臺上。并且會從線程池中移除當前Worker，并另啟一個新的Worker作為替代。

• 通過ThreadPoolExecutor的submit方法提交的任務，任務會先被包裝成FutureTask對象，出現異常后，異常會被生吞，并暫存到FutureTask對象中，作為任務執行結果的一部分。異常信息不會被打印，該子線程也不會被線程池移除（因為異常在子線程中被吞了，沒有拋出來）。在調用FutureTask上的get方法時（此時一般是在主線程中了），異常才會被拋出，觸發主線程的異常處理，并輸出到System.err

其他

其他的線程池場景

比如：

• 使用ScheduledThreadPoolExecutor實現延遲任務或者定時任務（周期任務），分析過程也是類似。這里給個簡單結論，當調用scheduleAtFixedRate方法執行一個周期任務時（任務會被包裝成FutureTask （實際是ScheduledFutureTask ，是FutureTask 的子類）），若周期任務中出現異常，異常會被生吞，異常信息不會被打印，線程不會被回收，但是周期任務執行這一次后就不會繼續執行了。ScheduledThreadPoolExecutor繼承了ThreadPoolExecutor，所以其也是復用了ThreadPoolExecutor的那一套邏輯。

• 使用CompletableFuture 的runAsync 提交任務，底層是通過ForkJoinPool 線程池進行執行，任務會被包裝成AsyncRun ，且會返回一個CompletableFuture 給主線程。當任務出現異常時，處理方式和ThreadPoolExecutor 的submit 類似，異常堆棧不會被打印。只有在CompletableFuture 上調用get 方法嘗試獲取結果時，異常才會被打印。

讀到這里，這篇“Java線程的異常處理機制是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。