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

Posted on by

前言

啟動一個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線程的異常處理機制詳情的文章就介紹到這瞭,更多相關Java線程異常處理內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：