背景介紹

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

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

線程池的基本工作原理

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

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

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

我們看下圖 1 所示：

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

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

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

看下圖 2 所示：

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

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

如下圖 3 所示：

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

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

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

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

如下圖 4 所示：

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

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

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

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

如下圖 5 所示：

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

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

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

如下圖 6 所示：

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

如下圖 7 所示：

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

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

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

如下圖 8 所示：

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

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

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

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

如下面的代碼所示：

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

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

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

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

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

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

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

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

}

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

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

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

如下圖 9 所示：

總結(jié)

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

希望大家學(xué)以致用，以后在項(xiàng)目里用線程池的時候，能夠靈活運(yùn)用咱們文章里學(xué)到的知識點(diǎn)。?