背景介紹

大家好，今天給大家講一個比較偏硬核技術類的知識，就是 Java 線程池在生產項目中的高并發優化。

可能很多兄弟都聽說過 Java 線程池的理論原理，知道他是怎么運作的，但是從來沒在項目里玩兒過 Java 線程池，更沒在高并發環境下玩兒過 Java 線程池的優化，所以今天我們來一起探討一下這個 Java 線程池在生產項目中的高并發優化!

線程池的基本工作原理

既然要聊線程池，那最起碼大家得大概知道一點兒 Java 線程池的基本工作原理，如果要把線程池原理講清楚，甚至剖析到 JDK 線程池的源碼層面，那可能得單獨開一篇文章來寫，這不是我們這次的主題，所以我們就把線程池最簡單的原理給大家講一下先。

線程池，簡單來說，就是他有一個池子，里面放了一堆的線程，這些線程一般是不會銷毀的，他們會一直存在，然后你可以不停的給線程池提交任務。

線程池會拿線程出來執行你的任務，任務執行完了以后，線程不會終止，他就繼續在線程池里待命就可以了。

我們看下圖 1 所示：

圖 1

但是這個時候會有一個關鍵的問題，那就是線程池里的線程數量通常是有限制的。

注意，這里說的是通常，因為 Java 線程池的真正原理來說，其實通過定制化手段，可以讓 Java 線程池有各種各樣不同的表現，我們這里就是說最基礎的一種情況，那就是線程池里的線程數量是固定的，而且是有限的。

所有如果說你要是一下子提交了太多的任務給線程池，然后此時所有的線程都在忙著運行自己的任務呢，這個時候你要是再想提交新的任務，你覺得會如何?任務能提交進去嗎?

看下圖 2 所示：

圖 2

那當然沒法提交進去了，但是此時難道線程池只能拒絕你嗎?那倒也不是，線程池為了應對這種情況，通常會設置一個隊列讓你提交任務，讓你的任務在隊列里等待一段時間，等有線程運行完了自己的任務，空閑出來了，再來運行這個隊列里的任務。

注意，這也是通常情況，因為 Java 線程池通過定制其實可以有別的表現，只不過通常線程池我們會這么設置而已。

如下圖 3 所示：

圖 3

線程池高并發場景下問題剖析

好那么接著問題來了，上面這個就是最最基礎的 Java 線程池的原理和用法，但是真正投入到一個生產項目里以后，他會遇到什么樣的問題呢?

首先最大的一個問題，就是提交到線程池里的任務，可能都是要執行各種網絡 IO 的任務。

比如說，RPC 調用其他的服務，或者說是后臺處理 DB 里大量的數據，所以很可能會導致線程運行完一個任務要耗費很長時間，從幾百毫秒到幾秒，甚至幾十秒，都有這種可能。

如下圖 4 所示：

圖 4

第二個問題，大家注意到上圖沒有，就是有的任務是 RPC 調用，可能僅僅是耗費幾百 ms，有的任務是大量數據操作，可能會耗費幾十秒。

所以說，其實一個公共的線程池里，運行了各種不同的任務，這就導致了線程池里的一個線程什么時候能執行完一個任務，那是不確定的，因為任務有可能是 RPC 調用，也可能是大數據量處理。

第三個問題，可能有一些任務是在一個 Http 請求里的，原本可能是在一個 Http 請求處理過程中，會依次處理多個耗時的任務。

現在為了優化性能，需要提交多個任務到線程池里，利用多個線程并發執行多個任務，提升本次請求的性能，這個 Http 請求需要等待這多個并發運行的任務都執行結束了，才會給用戶返回響應。

如下圖 5 所示：

圖 5

所以說，終極大問題來了，這種在生產項目里跑的線程池，因為提供給了各種不同的任務來共用，比如說定時 RPC 調用，定時大數據量處理，前臺 Http 請求多任務并發。

所以在生產環境繁忙期的時候，可能有如下場景：線程池此時正在運行多個定時 RPC 調用、定時大數據量處理的任務，這些任務又特別的耗時，導致很多線程都是忙碌狀態，少數線程是空閑狀態。

然后這個時候，系統剛好面向 C 端用戶提供的接口有高并發訪問的場景，大量 Http 請求過來，每個請求都要提交多個任務給線程池并發運行，導致線程池的少數空閑線程快速的跑滿，然后接著大量的任務進入了線程池的隊列開始排隊等待。

如下圖 6 所示：

圖 6

這個時候必然會導致大量的 Http 請求出現 hang 死的問題，因為很多 Http 請求的任務都在線程池里排隊等待，他們沒法運行，Http 請求也就沒法返回響應，給用戶的感覺就是點擊 APP/網頁一類的前端，點來點去沒反應，系統出現卡頓問題!

如下圖 7 所示：

圖 7

線程池高并發場景下性能優化

針對這種生產環境的問題，我們需要做的第一個最大的改善，就是把各種不同的任務從一個線程池里分離出來，讓他們互相之間不要影響。

也就是說，定時 RPC 任務就放一個線程池里去，定時 DB 大量數據處理任務放另外一個線程池里去，然后 Http 請求多任務并發處理放一個獨立的線程池，大家各自用自己的線程池和資源，互相之間不影響。

如下圖 8 所示：

圖 8

如上圖所做的話，我們有一個專門處理 Http 請求的線程池，這壓力一下子就下來了，因為 Http 請求的任務通常耗時都在幾十 ms 到一百 ms 級，整體速度很快，線程池里沒有定時 RPC 和定時 DB 訪問這種耗時任務進來搗亂了。

所以 Http 請求的專有線程池可以輕松+愉快的快速的處理所有 Http 請求的任務，即使是在高并發場景下，可以通過線程池增加線程資源來合理抗下高并發壓力。

另外就是對線上系統生產環境的線程池任務運行，我們通常會在公司里或者項目內研發統一的線程池監控框架。

所有的線程池任務都需要封裝到一個線程池監控框架提供的 Class 里，然后通過這個 Class 來實現任務的排隊等待與運行耗時的兩個維度的監控數據統計。

如下面的代碼所示：

// 線程任務包裝類，用了裝飾設計模式
public class RunnableWrapper implements Runnable {

    // 實際要執行的線程任務
    private Runnable task;
    // 線程任務被創建出來的時間
    private long createTime;
    // 線程任務被線程池運行的開始時間
    private long startTime;
    // 線程任務被線程池運行的結束時間
    private long endTime;

    // 當這個任務被創建出來的時候，就會設置他的創建時間
    // 但是接下來有可能這個任務提交到線程池后，會進入線程池的隊列排隊
    public RunnableWrapper(Runnable task) {
        this.task = task;
        this.createTime = new Date().getTime();
    }

    // 當任務在線程池排隊的時候，這個run方法是不會被運行的
    // 但是當任務結束了排隊，得到線程池運行機會的時候，這個方法會被調用
    // 此時就可以設置線程任務的開始運行時間
    public void run() {
        this.startTime = new Date().getTime();

        // 此處可以通過調用監控系統的API，實現監控指標上報
        // 用線程任務的startTime-createTime，其實就是任務排隊時間
        // monitor.report("threadName", "queueWaitTime", startTime-createTime);

        // 接著可以調用包裝的實際任務的run方法
        task.run();

        // 任務運行完畢以后，會設置任務運行結束的時間
        this.endTIme = new Date().getTime();

        // 此處可以通過調用監控系統的API，實現監控指標上報
        // 用線程任務的endTime - startTime，其實就是任務運行時間
        // monitor.report("threadName", "taskRunTime", endTime - startTime);
    }

}

大家通過上面的代碼可以清晰的看到，只要我們所有提交到線程池的任務，都用一個框架統一封裝的 RunnableWrapper 類，基于裝飾模式來進行包裝。

此時就可以得到線程任務的創建時間、開始時間、結束時間，接著就可以計算出這個任務的排隊耗時、運行耗時，通過監控系統進行上報。

此時我們通過在監控系統里配置告警條件，就可以實現不同線程池的每個任務的耗時指標上報，同時如果有某個線程池的某個線程排隊耗時或者運行耗時超過了我們配置的閾值，就會自動告警。

如下圖 9 所示：

圖 9

總結

好了，今天這篇文章到此為止，把我們的線程池在生產項目里的生產問題和高并發如何優化，以及生產環境下的監控方案，都告訴大家了。

希望大家學以致用，以后在項目里用線程池的時候，能夠靈活運用咱們文章里學到的知識點。