背景介紹

大家好，今天給大家講一個比較偏硬核技術(shù)類的知識，就是 Java 線程池在生產(chǎn)項目中的高并發(fā)優(yōu)化。

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

線程池的基本工作原理

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

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

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

我們看下圖 1 所示：

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

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

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

看下圖 2 所示：

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

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

如下圖 3 所示：

線程池高并發(fā)場景下問題剖析

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

首先最大的一個問題，就是提交到線程池里的任務(wù)，可能都是要執(zhí)行各種網(wǎng)絡(luò) IO 的任務(wù)。

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

如下圖 4 所示：

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

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

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

現(xiàn)在為了優(yōu)化性能，需要提交多個任務(wù)到線程池里，利用多個線程并發(fā)執(zhí)行多個任務(wù)，提升本次請求的性能，這個 Http 請求需要等待這多個并發(fā)運行的任務(wù)都執(zhí)行結(jié)束了，才會給用戶返回響應。

如下圖 5 所示：

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

所以在生產(chǎn)環(huán)境繁忙期的時候，可能有如下場景：線程池此時正在運行多個定時 RPC 調(diào)用、定時大數(shù)據(jù)量處理的任務(wù)，這些任務(wù)又特別的耗時，導致很多線程都是忙碌狀態(tài)，少數(shù)線程是空閑狀態(tài)。

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

如下圖 6 所示：

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

如下圖 7 所示：

線程池高并發(fā)場景下性能優(yōu)化

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

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

如下圖 8 所示：

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

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

另外就是對線上系統(tǒng)生產(chǎn)環(huán)境的線程池任務(wù)運行，我們通常會在公司里或者項目內(nèi)研發(fā)統(tǒng)一的線程池監(jiān)控框架。

所有的線程池任務(wù)都需要封裝到一個線程池監(jiān)控框架提供的 Class 里，然后通過這個 Class 來實現(xiàn)任務(wù)的排隊等待與運行耗時的兩個維度的監(jiān)控數(shù)據(jù)統(tǒng)計。

如下面的代碼所示：

// 線程任務(wù)包裝類，用了裝飾設(shè)計模式
public class RunnableWrapper implements Runnable {

    // 實際要執(zhí)行的線程任務(wù)
    private Runnable task;
    // 線程任務(wù)被創(chuàng)建出來的時間
    private long createTime;
    // 線程任務(wù)被線程池運行的開始時間
    private long startTime;
    // 線程任務(wù)被線程池運行的結(jié)束時間
    private long endTime;

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

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

        // 此處可以通過調(diào)用監(jiān)控系統(tǒng)的API，實現(xiàn)監(jiān)控指標上報
        // 用線程任務(wù)的startTime-createTime，其實就是任務(wù)排隊時間
        // monitor.report("threadName", "queueWaitTime", startTime-createTime);

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

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

        // 此處可以通過調(diào)用監(jiān)控系統(tǒng)的API，實現(xiàn)監(jiān)控指標上報
        // 用線程任務(wù)的endTime - startTime，其實就是任務(wù)運行時間
        // monitor.report("threadName", "taskRunTime", endTime - startTime);
    }

}

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

此時就可以得到線程任務(wù)的創(chuàng)建時間、開始時間、結(jié)束時間，接著就可以計算出這個任務(wù)的排隊耗時、運行耗時，通過監(jiān)控系統(tǒng)進行上報。

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

如下圖 9 所示：

總結(jié)

好了，今天這篇文章到此為止，把我們的線程池在生產(chǎn)項目里的生產(chǎn)問題和高并發(fā)如何優(yōu)化，以及生產(chǎn)環(huán)境下的監(jiān)控方案，都告訴大家了。

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