背景介紹

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

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

線程池的基本工作原理

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

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

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

我們看下圖 1 所示：

圖 1

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

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

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

看下圖 2 所示：

圖 2

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

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

如下圖 3 所示：

圖 3

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

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

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

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

如下圖 4 所示：

圖 4

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

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

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

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

如下圖 5 所示：

圖 5

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

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

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

如下圖 6 所示：

圖 6

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

如下圖 7 所示：

圖 7

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

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

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

如下圖 8 所示：

圖 8

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

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

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

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

如下面的代碼所示：

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

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

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

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

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

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

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

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

}

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

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

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

如下圖 9 所示：

圖 9

總結(jié)

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

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