執行緒池沒你想的那麼簡單（續）

crossoverJie發表於2019-06-06

執行緒

執行緒池沒你想的那麼簡單（續）

前言

前段時間寫過一篇《執行緒池沒你想的那麼簡單》，和大家一起擼了一個基本的執行緒池，具備：

執行緒池基本排程功能。
執行緒池自動擴容縮容。
佇列快取執行緒。
關閉執行緒池。

這些功能，最後也留下了三個待實現的 features 。

執行帶有返回值的執行緒。
異常處理怎麼辦？
所有任務執行完怎麼通知我？

這次就實現這三個特性來看看 j.u.c 中的執行緒池是如何實現這些需求的。

再看本文之前，強烈建議先檢視上文《執行緒池沒你想的那麼簡單》

任務完成後的通知

大家在用執行緒池的時候或多或少都會有這樣的需求：

執行緒池中的任務執行完畢後再通知主執行緒做其他事情，比如一批任務都執行完畢後再執行下一波任務等等。

執行緒池沒你想的那麼簡單（續）

以我們之前的程式碼為例：

總共往執行緒池中提交了 13 個任務，直到他們都執行完畢後再列印 “任務執行完畢” 這個日誌。

執行結果如下：

執行緒池沒你想的那麼簡單（續）

為了簡單的達到這個效果，我們可以在初始化執行緒池的時候傳入一個介面的實現，這個介面就是用於任務完成之後的回撥。

執行緒池沒你想的那麼簡單（續）

public interface Notify {

    /**
     * 回撥
     */
    void notifyListen() ;
}

以上就是執行緒池的建構函式以及介面的定義。

所以想要實現這個功能的關鍵是在何時回撥這個介面？

仔細想想其實也簡單：只要我們記錄提交到執行緒池中的任務及完成的數量，他們兩者的差為 0 時就認為執行緒池中的任務已執行完畢；這時便可回撥這個介面。

所以在往執行緒池中寫入任務時我們需要記錄任務數量：

執行緒池沒你想的那麼簡單（續）

為了併發安全的考慮，這裡的計數器採用了原子的 AtomicInteger 。

執行緒池沒你想的那麼簡單（續）

而在任務執行完畢後就將計數器 -1 ，一旦為 0 時則任務任務全部執行完畢；這時便可回撥我們自定義的介面完成通知。

JDK 的實現

這樣的需求在 jdk 中的 ThreadPoolExecutor 中也有相關的 API ，只是用法不太一樣，但本質原理都大同小異。

我們使用 ThreadPoolExecutor 的常規關閉流程如下：

    executorService.shutdown();
    while (!executorService.awaitTermination(100, TimeUnit.MILLISECONDS)) {
        logger.info("thread running");
    }

執行緒提交完畢後執行 shutdown() 關閉執行緒池，接著迴圈呼叫 awaitTermination() 方法，一旦任務全部執行完畢後則會返回 true 從而退出迴圈。

這兩個方法的目的和原理如下：

執行 shutdown() 後會將執行緒池的狀態置為關閉狀態，這時將會停止接收新的任務同時會等待佇列中的任務全部執行完畢後才真正關閉執行緒池。
awaitTermination 會阻塞直到執行緒池所有任務執行完畢或者超時時間已到。

為什麼要兩個 api 結合一起使用呢？

主要還在最終的目的是：所有執行緒執行完畢後再做某件事情，也就是線上程執行完畢之前其實主執行緒是需要被阻塞的。

shutdown() 執行後並不會阻塞，會立即返回，所有才需要後續用迴圈不停的呼叫 awaitTermination()，因為這個 api 才會阻塞執行緒。

其實我們檢視原始碼會發現，ThreadPoolExecutor 中的阻塞依然也是等待通知機制的運用，只不過用的是 LockSupport 的 API 而已。

帶有返回值的執行緒

接下來是帶有返回值的執行緒，這個需求也非常常見；比如需要執行緒非同步計算某些資料然後得到結果最終彙總使用。

先來看看如何使用（和 jdk 的類似）：

首先任務是不能實現 Runnable 介面了，畢竟他的 run() 函式是沒有返回值的；所以我們改實現一個 Callable 的介面：

執行緒池沒你想的那麼簡單（續）

這個介面有一個返回值。

同時在提交任務時也稍作改動：

執行緒池沒你想的那麼簡單（續）

首先是執行任務的函式由 execute() 換為了 submit()，同時他會返回一個返回值 Future，通過它便可拿到執行緒執行的結果。

最後通過第二步將所有執行結果列印出來：

執行緒池沒你想的那麼簡單（續）

實現原理

再看具體實現之前先來思考下這樣的功能如何實現？

首先受限於 jdk 的執行緒 api 的規範，要執行一個執行緒不管是實現介面還是繼承類，最終都是執行的 run() 函式。
所以我們想要一個執行緒有返回值無非只能是在執行 run() 函式時去呼叫一個有返回值的方法，再將這個返回值存放起來用於後續使用。

比如我們這裡新建了一個 Callable<T> 的介面：

public interface Callable<T> {

    /**
     * 執行任務
     * @return 執行結果
     */
    T call() ;
}

它的 call 函式就是剛才提到的有返回值的方法，所以我們應當線上程的 run() 函式中去呼叫它。

接著還會有一個 Future 的介面，他的主要作用是獲取執行緒的返回值，也就是 再將這個返回值存放起來用於後續使用 這裡提到的後續使用。

既然有了介面那自然就得有它的實現 FutureTask，它實現了 Future 介面用於後續獲取返回值。

同時實現了 Runnable 介面會把自己變為一個執行緒。

執行緒池沒你想的那麼簡單（續）

所以在它的 run() 函式中會呼叫剛才提到的具有返回值的 call() 函式。

再次結合 submit() 提交任務和 get() 獲取返回值的原始碼來看會更加理解這其中的門道。

    /**
     * 有返回值
     *
     * @param callable
     * @param <T>
     * @return
     */
    public <T> Future<T> submit(Callable<T> callable) {
        FutureTask<T> future = new FutureTask(callable);
        execute(future);
        return future;
    }

submit() 非常簡單，將我們丟進來的 Callable 物件轉換為一個 FutureTask 物件，然後再呼叫之前的 execute() 來丟進執行緒池（後續的流程就和一個普通的執行緒進入執行緒池的流程一樣）。