線程池如何按照core、max、queue的執行循序去執行

這是一個真實的面試題。

 

前幾天一個朋友在羣裏分享了他剛剛面試候選者時問的問題："線程池如何按照core、max、queue的執行循序去執行？"。

 

我們都知道線程池中代碼執行順序是：corePool->workQueue->maxPool，源碼我都看過，你現在問題讓我改源碼？？

 

一時間羣裏炸開了鍋，小夥伴們紛紛打聽他所在的公司，然後拉黑避坑。(手動狗頭，大家一起調侃٩(๑❛ᴗ❛๑)۶)

 

關於線程池他一共問了這麼幾個問題：

 

• 線程池如何按照core、max、queue的順序去執行？

• 子線程拋出的異常，主線程能感知到麼？

• 線程池發生了異常改怎樣處理？

 

但是針對這幾個問題，可能大家一時間也有點懵。今天的文章我們以源碼爲基礎來分析下該如何回答這三個問題。（之前沒閱讀過源碼也沒關係，所有的分析都會貼出源碼及圖解）

 

線程池如何按照core、max、queue的順序執行？

 

問題思考

 

對於這個問題，很多小夥伴肯定會疑惑："別人源碼中寫好的執行流程你爲啥要改？這面試官腦子有病吧……"

 

這裏來思考一下現實工作場景中是否有這種需求？之前也看到過一份簡歷也寫到過這個問題：

 

場景描述.png

 

一個線程池執行的任務屬於IO密集型，CPU大多屬於閒置狀態，系統資源未充分利用。如果一瞬間來了大量請求，如果線程池數量大於coreSize時，多餘的請求都會放入到等待隊列中。等待着corePool中的線程執行完成後再來執行等待隊列中的任務。

 

試想一下，這種場景我們該如何優化？

 

我們可以修改線程池的執行順序爲corePool->maxPool->workQueue。這樣就能夠充分利用CPU資源，提交的任務會被優先執行。當線程池中線程數量大於maxSize時纔會將任務放入等待隊列中。

 

你就說巧不巧？面試官的這個問題顯然是經過認真思考來提問的，這是一個很有意思的問題，下面就一起看看如何解決吧。

 

線程池運行流程

 

我們都知道線程池執行流程是先corePool再workQueue，最後纔是maxPool的一個執行流程。

 

執行流程.png

 

線程池核心參數

 

在回顧下ThreadPoolExecutor.execute()源碼前我們先回顧下線程池中的幾個重要參數：

線程池核心參數.png

 

我們來看下這幾個參數的定義：

corePoolSize: 線程池中核心線程數量

maximumPoolSize: 線程池中最大線程數量

keepAliveTime: 非核心的空閒線程等待新任務的時間

unit: 時間單位。配合allowCoreThreadTimeOut也會清理核心線程池中的線程。

workQueue: 基於Blocking的任務隊列，最好選用有界隊列，指定隊列長度

threadFactory: 線程工廠，最好自定義線程工廠，可以自定義每個線程的名稱

handler: 拒絕策略，默認是AbortPolicy

 

ThreadPoolExecutor.execute()源碼分析

 

我們可以看下execute()如下：

execute執行源碼.png

 

接着來分析下執行過程：

 

1. 第一步：workerCountOf(c)時間計算當前線程池中線程的個數，當線程個數小於核心線程數

    

2. 第二步：線程池線程數量大於核心線程數，此時提交的任務會放入workQueue中，使用offer()進行操作

    

3. 第三步：workQueue.offer()執行失敗，新提交的任務會直接執行，addWorker()會判斷如果當前線程池數量大於最大線程數，則執行拒絕策略

 

好了，到了這裏我們都已經很清楚了，關鍵在於第二步和第三步如何交換順序執行呢？

 

解決思路

 

仔細想一想，如果修改workQueue.offer()的實現不就可以達到目的了？我們先來畫圖來看一下：

 

問題思路.png

 

現在的問題就在於，如果當前線程池中coreSize < workCount < maxSize時，一定會先執行offer()操作。

 

我們如果修改offer的實現是否可以完成執行順序的更換呢？這裏也是畫圖來展示一下：

解決方式.png

 

Dubbo中EagerThreadPool解決方案

 

湊巧Dubbo中也有類似的實現，在Dubbo的EagerThreadPool自定義了一個BlockingQueue，在offer()方法中，如果當前線程池數量小於最大線程池時，直接返回false，這裏就達到了調節線程池執行順序的目的。

 

dubbo中解決方案.png

 

 

源碼直達：https://github.com/apache/dubbo/blob/master/dubbo-common/src/main/java/org/apache/dubbo/common/threadpool/support/eager/TaskQueue.java

 

看到這裏一切都真相大白了，解決思路以及方案都很簡單，學會了沒有？

 

這個問題背後還隱藏了一些場景的優化、源碼的擴展等等知識，果然是一個值得思考的好問題。

 

子線程拋出的異常，主線程能感知到麼？

 

問題思考

 

這個問題其實也很容易回答，也僅僅是一個面試題而已，實際工作中子線程的異常不應該由主線程來捕獲。

 

針對這個問題，希望大家清楚的是： 我們要明確線程代碼的邊界，異步化過程中，子線程拋出的異常應該由子線程自己去處理，而不是需要主線程感知來協助處理。

 

解決方案

 

解決方案很簡單，在虛擬機中，當一個線程如果沒有顯式處理異常而拋出時會將該異常事件報告給該線程對象的 java.lang.Thread.UncaughtExceptionHandler 進行處理，如果線程沒有設置 UncaughtExceptionHandler，則默認會把異常棧信息輸出到終端而使程序直接崩潰。

 

所以如果我們想在線程意外崩潰時做一些處理就可以通過實現 UncaughtExceptionHandler 來滿足需求。

 

我們使用線程池設置ThreadFactory時可以指定UncaughtExceptionHandler，這樣就可以捕獲到子線程拋出的異常了。

 

代碼示例

 

具體代碼如下：

 

/** * 測試子線程異常問題 * * @author wangmeng * @date 2020/6/13 18:08 */public class ThreadPoolExceptionTest {
    public static void main(String[] args) throws InterruptedException {        MyHandler myHandler = new MyHandler();        ExecutorService execute = new ThreadPoolExecutor(10, 10,                0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), new ThreadFactoryBuilder().setUncaughtExceptionHandler(myHandler).build());
        TimeUnit.SECONDS.sleep(5);        for (int i = 0; i < 10; i++) {            execute.execute(new MyRunner());        }    }

    private static class MyRunner implements Runnable {        @Override        public void run() {            int count = 0;            while (true) {                count++;                System.out.println("我要開始生產Bug了============");                if (count == 10) {                    System.out.println(1 / 0);                }
                if (count == 20) {                    System.out.println("這裏是不會執行到的==========");                    break;                }            }        }    }}
class MyHandler implements Thread.UncaughtExceptionHandler {    private final static Logger LOGGER = LoggerFactory.getLogger(MyHandler.class);    @Override    public void uncaughtException(Thread t, Throwable e) {        LOGGER.error("threadId = {}, threadName = {}, ex = {}", t.getId(), t.getName(), e.getMessage());    }}

 

執行結果：

執行結果.png

 

UncaughtExceptionHandler 解析

 

我們來看下Thread中的內部接口UncaughtExceptionHandler：

 

public class Thread {    ......    /**     * 當一個線程因未捕獲的異常而即將終止時虛擬機將使用 Thread.getUncaughtExceptionHandler()     * 獲取已經設置的 UncaughtExceptionHandler 實例，並通過調用其 uncaughtException(...) 方     * 法而傳遞相關異常信息。     * 如果一個線程沒有明確設置其 UncaughtExceptionHandler，則將其 ThreadGroup 對象作爲其     * handler，如果 ThreadGroup 對象對異常沒有什麼特殊的要求，則 ThreadGroup 會將調用轉發給     * 默認的未捕獲異常處理器（即 Thread 類中定義的靜態未捕獲異常處理器對象）。     *     * @see #setDefaultUncaughtExceptionHandler     * @see #setUncaughtExceptionHandler     * @see ThreadGroup#uncaughtException     */    @FunctionalInterface    public interface UncaughtExceptionHandler {        /**         * 未捕獲異常崩潰時回調此方法         */        void uncaughtException(Thread t, Throwable e);    }
    /**     * 靜態方法，用於設置一個默認的全局異常處理器。     */    public static void setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler eh) {         defaultUncaughtExceptionHandler = eh;     }
    /**     * 針對某個 Thread 對象的方法，用於對特定的線程進行未捕獲的異常處理。     */    public void setUncaughtExceptionHandler(UncaughtExceptionHandler eh) {        checkAccess();        uncaughtExceptionHandler = eh;    }
    /**     * 當 Thread 崩潰時會調用該方法獲取當前線程的 handler，獲取不到就會調用 group（handler 類型）。     * group 是 Thread 類的 ThreadGroup 類型屬性，在 Thread 構造中實例化。     */    public UncaughtExceptionHandler getUncaughtExceptionHandler() {        return uncaughtExceptionHandler != null ?            uncaughtExceptionHandler : group;    }
    /**     * 線程全局默認 handler。     */    public static UncaughtExceptionHandler getDefaultUncaughtExceptionHandler() {        return defaultUncaughtExceptionHandler;    }    ......}

 

線程池發生了異常該怎樣處理？

 

線程池中線程運行過程中出現了異常該怎樣處理呢？線程池提交任務有兩種方式，分別是execute()和submit()，這裏會依次說明。

 

ThreadPoolExecutor.runWorker()實現

 

不管是使用execute()還是submit()提交任務，最終都會執行到ThreadPoolExecutor.runWorker()，我們來看下源碼（源碼基於JDK1.8）：

runWorker().png

 

我們看到在執行task.run()時，出現異常會直接向上拋出，這裏處理的最好的方式就是在我們業務代碼中使用try...catch()來捕獲異常。

 

FutureTask.run()實現

 

如果我們使用submit()來提交任務，在ThreadPoolExecutor.runWorker()方法執行時最終會調用到FutureTask.run()方法裏面去，不清楚的小夥伴也可以看下我之前的文章：

 

線程池續：你必須要知道的線程池submit()實現原理之FutureTask！

 

這裏可以看到，如果業務代碼拋出異常後，會被catch捕獲到，然後調用setExeception()方法：

 

 

可以看到其實類似於直接吞掉了，當我們調用get()方法的時候異常信息會包裝到FutureTask內部的變量outcome中，我們也會獲取到對應的異常信息。

 

在ThreadPoolExecutor.runWorker()最後finally中有一個afterExecute()鉤子方法，如果我們重寫了afterExecute()方法，就可以獲取到子線程拋出的具體異常信息Throwable了。

 

結論

 

對於線程池、包括線程的異常處理推薦以下方式:

 

1. 直接使用try/catch，這個也是最推薦的方式

    

    

2. 在我們構造線程池的時候，重寫uncaughtException()方法，上面示例代碼也有提到：

   public class ThreadPoolExceptionTest {
       public static void main(String[] args) throws InterruptedException {        MyHandler myHandler = new MyHandler();        ExecutorService execute = new ThreadPoolExecutor(10, 10,                0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(), new ThreadFactoryBuilder().setUncaughtExceptionHandler(myHandler).build());
           TimeUnit.SECONDS.sleep(5);        for (int i = 0; i < 10; i++) {            execute.execute(new MyRunner());        }    }}
   class MyHandler implements Thread.UncaughtExceptionHandler {    private final static Logger LOGGER = LoggerFactory.getLogger(MyHandler.class);    @Override    public void uncaughtException(Thread t, Throwable e) {        LOGGER.error("threadId = {}, threadName = {}, ex = {}", t.getId(), t.getName(), e.getMessage());    }}

    

3. 直接重寫afterExecute()方法，感知異常細節