當(dāng)前大部分的java應(yīng)用都會用到線程池刮便，但是線程的參數(shù)設(shè)置是一個無法預(yù)估的值褪秀，必須要根據(jù)線上的實際情況來確定線程池的相關(guān)參數(shù)蓄诽，且需要重啟應(yīng)用。

在這里感謝美團(tuán)技術(shù)團(tuán)隊的分享媒吗，關(guān)于動態(tài)線程池的設(shè)計思路若专。

一、寫在前面

1.1 線程池是什么

線程池（Thread Pool）是一種基于池化思想管理線程的工具蝴猪，經(jīng)常出現(xiàn)在多線程服務(wù)器中调衰，如MySQL。

線程過多會帶來額外的開銷自阱，其中包括創(chuàng)建銷毀線程的開銷嚎莉、調(diào)度線程的開銷等等，同時也降低了計算機(jī)的整體性能沛豌。線程池維護(hù)多個線程趋箩，等待監(jiān)督管理者分配可并發(fā)執(zhí)行的任務(wù)赃额。這種做法，一方面避免了處理任務(wù)時創(chuàng)建銷毀線程開銷的代價叫确，另一方面避免了線程數(shù)量膨脹導(dǎo)致的過分調(diào)度問題跳芳，保證了對內(nèi)核的充分利用。

而本文描述線程池是JDK中提供的ThreadPoolExecutor類竹勉。

當(dāng)然飞盆，使用線程池可以帶來一系列好處：

降低資源消耗：通過池化技術(shù)重復(fù)利用已創(chuàng)建的線程，降低線程創(chuàng)建和銷毀造成的損耗次乓。

提高響應(yīng)速度：任務(wù)到達(dá)時吓歇，無需等待線程創(chuàng)建即可立即執(zhí)行。

提高線程的可管理性：線程是稀缺資源票腰，如果無限制創(chuàng)建城看，不僅會消耗系統(tǒng)資源，還會因為線程的不合理分布導(dǎo)致資源調(diào)度失衡杏慰，降低系統(tǒng)的穩(wěn)定性测柠。使用線程池可以進(jìn)行統(tǒng)一的分配、調(diào)優(yōu)和監(jiān)控缘滥。

提供更多更強(qiáng)大的功能：線程池具備可拓展性轰胁，允許開發(fā)人員向其中增加更多的功能。比如延時定時線程池ScheduledThreadPoolExecutor完域，就允許任務(wù)延期執(zhí)行或定期執(zhí)行软吐。

1.2 線程池解決的問題是什么

線程池解決的核心問題就是資源管理問題。在并發(fā)環(huán)境下吟税，系統(tǒng)不能夠確定在任意時刻中凹耙，有多少任務(wù)需要執(zhí)行，有多少資源需要投入肠仪。這種不確定性將帶來以下若干問題：

頻繁申請/銷毀資源和調(diào)度資源肖抱，將帶來額外的消耗，可能會非常巨大异旧。

對資源無限申請缺少抑制手段意述，易引發(fā)系統(tǒng)資源耗盡的風(fēng)險。

系統(tǒng)無法合理管理內(nèi)部的資源分布吮蛹，會降低系統(tǒng)的穩(wěn)定性荤崇。

為解決資源分配這個問題，線程池采用了“池化”（Pooling）思想潮针。池化术荤，顧名思義，是為了最大化收益并最小化風(fēng)險每篷，而將資源統(tǒng)一在一起管理的一種思想瓣戚。

Pooling is the grouping together of resources (assets, equipment, personnel, effort, etc.) for the purposes of maximizing advantage or minimizing risk to the users. The term is used in finance, computing and equipment management.——wikipedia

“池化”思想不僅僅能應(yīng)用在計算機(jī)領(lǐng)域端圈，在金融、設(shè)備子库、人員管理舱权、工作管理等領(lǐng)域也有相關(guān)的應(yīng)用。

在計算機(jī)領(lǐng)域中的表現(xiàn)為：統(tǒng)一管理IT資源仑嗅，包括服務(wù)器宴倍、存儲、和網(wǎng)絡(luò)資源等等无畔。通過共享資源啊楚，使用戶在低投入中獲益吠冤。除去線程池浑彰，還有其他比較典型的幾種使用策略包括：

內(nèi)存池(Memory Pooling)：預(yù)先申請內(nèi)存，提升申請內(nèi)存速度拯辙，減少內(nèi)存碎片郭变。

連接池(Connection Pooling)：預(yù)先申請數(shù)據(jù)庫連接，提升申請連接的速度涯保，降低系統(tǒng)的開銷诉濒。

實例池(Object Pooling)：循環(huán)使用對象，減少資源在初始化和釋放時的昂貴損耗夕春。

在了解完“是什么”和“為什么”之后未荒，下面我們來一起深入一下線程池的內(nèi)部實現(xiàn)原理。

二及志、線程池核心設(shè)計與實現(xiàn)

在前文中片排，我們了解到：線程池是一種通過“池化”思想，幫助我們管理線程而獲取并發(fā)性的工具速侈，在Java中的體現(xiàn)是ThreadPoolExecutor類率寡。那么它的的詳細(xì)設(shè)計與實現(xiàn)是什么樣的呢？我們會在本章進(jìn)行詳細(xì)介紹倚搬。

2.1 總體設(shè)計

Java中的線程池核心實現(xiàn)類是ThreadPoolExecutor冶共，本章基于JDK 1.8的源碼來分析Java線程池的核心設(shè)計與實現(xiàn)。我們首先來看一下ThreadPoolExecutor的UML類圖每界，了解下ThreadPoolExecutor的繼承關(guān)系捅僵。

圖1 ThreadPoolExecutor UML類圖

ThreadPoolExecutor實現(xiàn)的頂層接口是Executor，頂層接口Executor提供了一種思想：將任務(wù)提交和任務(wù)執(zhí)行進(jìn)行解耦眨层。用戶無需關(guān)注如何創(chuàng)建線程庙楚，如何調(diào)度線程來執(zhí)行任務(wù)，用戶只需提供Runnable對象谐岁，將任務(wù)的運行邏輯提交到執(zhí)行器(Executor)中醋奠，由Executor框架完成線程的調(diào)配和任務(wù)的執(zhí)行部分榛臼。ExecutorService接口增加了一些能力：（1）擴(kuò)充執(zhí)行任務(wù)的能力，補(bǔ)充可以為一個或一批異步任務(wù)生成Future的方法窜司；（2）提供了管控線程池的方法沛善，比如停止線程池的運行。

AbstractExecutorService則是上層的抽象類塞祈，將執(zhí)行任務(wù)的流程串聯(lián)了起來金刁，保證下層的實現(xiàn)只需關(guān)注一個執(zhí)行任務(wù)的方法即可。最下層的實現(xiàn)類ThreadPoolExecutor實現(xiàn)最復(fù)雜的運行部分议薪，ThreadPoolExecutor將會一方面維護(hù)自身的生命周期尤蛮，另一方面同時管理線程和任務(wù)，使兩者良好的結(jié)合從而執(zhí)行并行任務(wù)斯议。

ThreadPoolExecutor是如何運行产捞，如何同時維護(hù)線程和執(zhí)行任務(wù)的呢？其運行機(jī)制如下圖所示：

圖2 ThreadPoolExecutor運行流程

線程池在內(nèi)部實際上構(gòu)建了一個生產(chǎn)者消費者模型哼御，將線程和任務(wù)兩者解耦坯临，并不直接關(guān)聯(lián)，從而良好的緩沖任務(wù)恋昼，復(fù)用線程看靠。線程池的運行主要分成兩部分：任務(wù)管理、線程管理液肌。任務(wù)管理部分充當(dāng)生產(chǎn)者的角色挟炬，當(dāng)任務(wù)提交后，線程池會判斷該任務(wù)后續(xù)的流轉(zhuǎn)：（1）直接申請線程執(zhí)行該任務(wù)嗦哆；（2）緩沖到隊列中等待線程執(zhí)行谤祖；（3）拒絕該任務(wù)。線程管理部分是消費者吝秕，它們被統(tǒng)一維護(hù)在線程池內(nèi)泊脐，根據(jù)任務(wù)請求進(jìn)行線程的分配，當(dāng)線程執(zhí)行完任務(wù)后則會繼續(xù)獲取新的任務(wù)去執(zhí)行烁峭，最終當(dāng)線程獲取不到任務(wù)的時候容客，線程就會被回收。

接下來约郁，我們會按照以下三個部分去詳細(xì)講解線程池運行機(jī)制：

線程池如何維護(hù)自身狀態(tài)缩挑。

線程池如何管理任務(wù)。

線程池如何管理線程鬓梅。

2.2 生命周期管理

線程池運行的狀態(tài)供置，并不是用戶顯式設(shè)置的，而是伴隨著線程池的運行绽快，由內(nèi)部來維護(hù)芥丧。線程池內(nèi)部使用一個變量維護(hù)兩個值：運行狀態(tài)(runState)和線程數(shù)量 (workerCount)紧阔。在具體實現(xiàn)中，線程池將運行狀態(tài)(runState)续担、線程數(shù)量 (workerCount)兩個關(guān)鍵參數(shù)的維護(hù)放在了一起擅耽，如下代碼所示：

privatefinalAtomicInteger?ctl?=newAtomicInteger(ctlOf(RUNNING,0));

ctl這個AtomicInteger類型，是對線程池的運行狀態(tài)和線程池中有效線程的數(shù)量進(jìn)行控制的一個字段物遇， 它同時包含兩部分的信息：線程池的運行狀態(tài) (runState) 和線程池內(nèi)有效線程的數(shù)量 (workerCount)乖仇，高3位保存runState，低29位保存workerCount询兴，兩個變量之間互不干擾乃沙。用一個變量去存儲兩個值，可避免在做相關(guān)決策時诗舰，出現(xiàn)不一致的情況警儒，不必為了維護(hù)兩者的一致，而占用鎖資源始衅。通過閱讀線程池源代碼也可以發(fā)現(xiàn)冷蚂，經(jīng)常出現(xiàn)要同時判斷線程池運行狀態(tài)和線程數(shù)量的情況缭保。線程池也提供了若干方法去供用戶獲得線程池當(dāng)前的運行狀態(tài)汛闸、線程個數(shù)娘扩。這里都使用的是位運算的方式齐婴，相比于基本運算，速度也會快很多宗雇。

關(guān)于內(nèi)部封裝的獲取生命周期狀態(tài)钳恕、獲取線程池線程數(shù)量的計算方法如以下代碼所示：

privatestaticintrunStateOf(intc){returnc?&?~CAPACITY;?}//計算當(dāng)前運行狀態(tài)

privatestaticintworkerCountOf(intc){returnc?&?CAPACITY;?}//計算當(dāng)前線程數(shù)量

privatestaticintctlOf(intrs,intwc){returnrs?|?wc;?}//通過狀態(tài)和線程數(shù)生成ctl

ThreadPoolExecutor的運行狀態(tài)有5種别伏，分別為：

其生命周期轉(zhuǎn)換如下入所示：

圖3 線程池生命周期

2.3 任務(wù)執(zhí)行機(jī)制

2.3.1 任務(wù)調(diào)度

任務(wù)調(diào)度是線程池的主要入口，當(dāng)用戶提交了一個任務(wù)忧额，接下來這個任務(wù)將如何執(zhí)行都是由這個階段決定的厘肮。了解這部分就相當(dāng)于了解了線程池的核心運行機(jī)制。

首先睦番，所有任務(wù)的調(diào)度都是由execute方法完成的类茂，這部分完成的工作是：檢查現(xiàn)在線程池的運行狀態(tài)、運行線程數(shù)托嚣、運行策略巩检，決定接下來執(zhí)行的流程，是直接申請線程執(zhí)行示启，或是緩沖到隊列中執(zhí)行兢哭，亦或是直接拒絕該任務(wù)。其執(zhí)行過程如下：

首先檢測線程池運行狀態(tài)夫嗓，如果不是RUNNING迟螺，則直接拒絕冲秽，線程池要保證在RUNNING的狀態(tài)下執(zhí)行任務(wù)。

如果workerCount < corePoolSize矩父，則創(chuàng)建并啟動一個線程來執(zhí)行新提交的任務(wù)劳跃。

如果workerCount >= corePoolSize，且線程池內(nèi)的阻塞隊列未滿浙垫，則將任務(wù)添加到該阻塞隊列中刨仑。

如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且線程池內(nèi)的阻塞隊列已滿夹姥，則創(chuàng)建并啟動一個線程來執(zhí)行新提交的任務(wù)杉武。

如果workerCount >= maximumPoolSize，并且線程池內(nèi)的阻塞隊列已滿, 則根據(jù)拒絕策略來處理該任務(wù), 默認(rèn)的處理方式是直接拋異常辙售。

其執(zhí)行流程如下圖所示：

圖4 任務(wù)調(diào)度流程

2.3.2 任務(wù)緩沖

任務(wù)緩沖模塊是線程池能夠管理任務(wù)的核心部分轻抱。線程池的本質(zhì)是對任務(wù)和線程的管理，而做到這一點最關(guān)鍵的思想就是將任務(wù)和線程兩者解耦旦部，不讓兩者直接關(guān)聯(lián)祈搜，才可以做后續(xù)的分配工作。線程池中是以生產(chǎn)者消費者模式士八，通過一個阻塞隊列來實現(xiàn)的容燕。阻塞隊列緩存任務(wù)，工作線程從阻塞隊列中獲取任務(wù)婚度。

阻塞隊列(BlockingQueue)是一個支持兩個附加操作的隊列蘸秘。這兩個附加的操作是：在隊列為空時，獲取元素的線程會等待隊列變?yōu)榉强栈茸隆．?dāng)隊列滿時醋虏，存儲元素的線程會等待隊列可用。阻塞隊列常用于生產(chǎn)者和消費者的場景哮翘，生產(chǎn)者是往隊列里添加元素的線程颈嚼，消費者是從隊列里拿元素的線程。阻塞隊列就是生產(chǎn)者存放元素的容器饭寺，而消費者也只從容器里拿元素阻课。

下圖中展示了線程1往阻塞隊列中添加元素，而線程2從阻塞隊列中移除元素：

圖5 阻塞隊列

使用不同的隊列可以實現(xiàn)不一樣的任務(wù)存取策略佩研。在這里柑肴，我們可以再介紹下阻塞隊列的成員：

2.3.3 任務(wù)申請

由上文的任務(wù)分配部分可知，任務(wù)的執(zhí)行有兩種可能：一種是任務(wù)直接由新創(chuàng)建的線程執(zhí)行旬薯。另一種是線程從任務(wù)隊列中獲取任務(wù)然后執(zhí)行晰骑，執(zhí)行完任務(wù)的空閑線程會再次去從隊列中申請任務(wù)再去執(zhí)行。第一種情況僅出現(xiàn)在線程初始創(chuàng)建的時候，第二種是線程獲取任務(wù)絕大多數(shù)的情況硕舆。

線程需要從任務(wù)緩存模塊中不斷地取任務(wù)執(zhí)行秽荞，幫助線程從阻塞隊列中獲取任務(wù)，實現(xiàn)線程管理模塊和任務(wù)管理模塊之間的通信抚官。這部分策略由getTask方法實現(xiàn)扬跋，其執(zhí)行流程如下圖所示：

圖6 獲取任務(wù)流程圖

getTask這部分進(jìn)行了多次判斷，為的是控制線程的數(shù)量凌节，使其符合線程池的狀態(tài)钦听。如果線程池現(xiàn)在不應(yīng)該持有那么多線程，則會返回null值倍奢。工作線程Worker會不斷接收新任務(wù)去執(zhí)行朴上，而當(dāng)工作線程Worker接收不到任務(wù)的時候，就會開始被回收卒煞。

2.3.4 任務(wù)拒絕

任務(wù)拒絕模塊是線程池的保護(hù)部分痪宰，線程池有一個最大的容量，當(dāng)線程池的任務(wù)緩存隊列已滿畔裕，并且線程池中的線程數(shù)目達(dá)到maximumPoolSize時衣撬，就需要拒絕掉該任務(wù)，采取任務(wù)拒絕策略扮饶，保護(hù)線程池具练。

拒絕策略是一個接口，其設(shè)計如下：

publicinterfaceRejectedExecutionHandler{

voidrejectedExecution(Runnable?r,?ThreadPoolExecutor?executor);

}

用戶可以通過實現(xiàn)這個接口去定制拒絕策略贴届，也可以選擇JDK提供的四種已有拒絕策略靠粪，其特點如下：

2.4 Worker線程管理

2.4.1 Worker線程

線程池為了掌握線程的狀態(tài)并維護(hù)線程的生命周期，設(shè)計了線程池內(nèi)的工作線程Worker毫蚓。我們來看一下它的部分代碼：

privatefinalclassWorkerextendsAbstractQueuedSynchronizerimplementsRunnable{

????finalThread?thread;//Worker持有的線程

Runnable?firstTask;//初始化的任務(wù)，可以為null

}

Worker這個工作線程昔善，實現(xiàn)了Runnable接口元潘，并持有一個線程thread，一個初始化的任務(wù)firstTask君仆。thread是在調(diào)用構(gòu)造方法時通過ThreadFactory來創(chuàng)建的線程翩概，可以用來執(zhí)行任務(wù)；firstTask用它來保存?zhèn)魅氲牡谝粋€任務(wù)返咱，這個任務(wù)可以有也可以為null钥庇。如果這個值是非空的，那么線程就會在啟動初期立即執(zhí)行這個任務(wù)咖摹，也就對應(yīng)核心線程創(chuàng)建時的情況评姨；如果這個值是null，那么就需要創(chuàng)建一個線程去執(zhí)行任務(wù)列表（workQueue）中的任務(wù)萤晴，也就是非核心線程的創(chuàng)建吐句。

Worker執(zhí)行任務(wù)的模型如下圖所示：

圖7 Worker執(zhí)行任務(wù)

線程池需要管理線程的生命周期胁后，需要在線程長時間不運行的時候進(jìn)行回收。線程池使用一張Hash表去持有線程的引用嗦枢，這樣可以通過添加引用攀芯、移除引用這樣的操作來控制線程的生命周期。這個時候重要的就是如何判斷線程是否在運行文虏。

Worker是通過繼承AQS侣诺，使用AQS來實現(xiàn)獨占鎖這個功能。沒有使用可重入鎖ReentrantLock氧秘，而是使用AQS紧武，為的就是實現(xiàn)不可重入的特性去反應(yīng)線程現(xiàn)在的執(zhí)行狀態(tài)。

lock方法一旦獲取了獨占鎖敏储，表示當(dāng)前線程正在執(zhí)行任務(wù)中阻星。

如果正在執(zhí)行任務(wù)，則不應(yīng)該中斷線程已添。

如果該線程現(xiàn)在不是獨占鎖的狀態(tài)妥箕，也就是空閑的狀態(tài)，說明它沒有在處理任務(wù)更舞，這時可以對該線程進(jìn)行中斷畦幢。

線程池在執(zhí)行shutdown方法或tryTerminate方法時會調(diào)用interruptIdleWorkers方法來中斷空閑的線程，interruptIdleWorkers方法會使用tryLock方法來判斷線程池中的線程是否是空閑狀態(tài)缆蝉；如果線程是空閑狀態(tài)則可以安全回收宇葱。

在線程回收過程中就使用到了這種特性，回收過程如下圖所示：

圖8 線程池回收過程

2.4.2 Worker線程增加

增加線程是通過線程池中的addWorker方法刊头，該方法的功能就是增加一個線程黍瞧，該方法不考慮線程池是在哪個階段增加的該線程，這個分配線程的策略是在上個步驟完成的原杂，該步驟僅僅完成增加線程印颤，并使它運行，最后返回是否成功這個結(jié)果穿肄。addWorker方法有兩個參數(shù)：firstTask年局、core。firstTask參數(shù)用于指定新增的線程執(zhí)行的第一個任務(wù)咸产，該參數(shù)可以為空矢否；core參數(shù)為true表示在新增線程時會判斷當(dāng)前活動線程數(shù)是否少于corePoolSize，false表示新增線程前需要判斷當(dāng)前活動線程數(shù)是否少于maximumPoolSize脑溢，其執(zhí)行流程如下圖所示：

圖9 申請線程執(zhí)行流程圖

2.4.3 Worker線程回收

線程池中線程的銷毀依賴JVM自動的回收僵朗，線程池做的工作是根據(jù)當(dāng)前線程池的狀態(tài)維護(hù)一定數(shù)量的線程引用，防止這部分線程被JVM回收，當(dāng)線程池決定哪些線程需要回收時衣迷，只需要將其引用消除即可畏鼓。Worker被創(chuàng)建出來后，就會不斷地進(jìn)行輪詢壶谒，然后獲取任務(wù)去執(zhí)行云矫，核心線程可以無限等待獲取任務(wù)，非核心線程要限時獲取任務(wù)汗菜。當(dāng)Worker無法獲取到任務(wù)让禀，也就是獲取的任務(wù)為空時，循環(huán)會結(jié)束陨界，Worker會主動消除自身在線程池內(nèi)的引用巡揍。

try{

while(task?!=null||?(task?=?getTask())?!=null)?{

//執(zhí)行任務(wù)

}

}finally{

processWorkerExit(w,?completedAbruptly);//獲取不到任務(wù)時，主動回收自己

}

線程回收的工作是在processWorkerExit方法完成的菌瘪。

圖10 線程銷毀流程

事實上腮敌，在這個方法中，將線程引用移出線程池就已經(jīng)結(jié)束了線程銷毀的部分俏扩。但由于引起線程銷毀的可能性有很多糜工，線程池還要判斷是什么引發(fā)了這次銷毀，是否要改變線程池的現(xiàn)階段狀態(tài)录淡，是否要根據(jù)新狀態(tài)捌木，重新分配線程。

2.4.4 Worker線程執(zhí)行任務(wù)

在Worker類中的run方法調(diào)用了runWorker方法來執(zhí)行任務(wù)嫉戚，runWorker方法的執(zhí)行過程如下：

while循環(huán)不斷地通過getTask()方法獲取任務(wù)刨裆。

getTask()方法從阻塞隊列中取任務(wù)。

如果線程池正在停止彬檀，那么要保證當(dāng)前線程是中斷狀態(tài)帆啃，否則要保證當(dāng)前線程不是中斷狀態(tài)。

執(zhí)行任務(wù)凤覆。

如果getTask結(jié)果為null則跳出循環(huán)链瓦，執(zhí)行processWorkerExit()方法，銷毀線程盯桦。

執(zhí)行流程如下圖所示：

圖11 執(zhí)行任務(wù)流程

三、線程池在業(yè)務(wù)中的實踐

3.1 業(yè)務(wù)背景

在當(dāng)今的互聯(lián)網(wǎng)業(yè)界渤刃，為了最大程度利用CPU的多核性能拥峦，并行運算的能力是不可或缺的。通過線程池管理線程獲取并發(fā)性是一個非陈糇樱基礎(chǔ)的操作略号，讓我們來看兩個典型的使用線程池獲取并發(fā)性的場景。

場景1：快速響應(yīng)用戶請求

描述：用戶發(fā)起的實時請求，服務(wù)追求響應(yīng)時間玄柠。比如說用戶要查看一個商品的信息突梦，那么我們需要將商品維度的一系列信息如商品的價格、優(yōu)惠羽利、庫存宫患、圖片等等聚合起來，展示給用戶这弧。

分析：從用戶體驗角度看娃闲，這個結(jié)果響應(yīng)的越快越好，如果一個頁面半天都刷不出匾浪，用戶可能就放棄查看這個商品了皇帮。而面向用戶的功能聚合通常非常復(fù)雜，伴隨著調(diào)用與調(diào)用之間的級聯(lián)蛋辈、多級級聯(lián)等情況属拾，業(yè)務(wù)開發(fā)同學(xué)往往會選擇使用線程池這種簡單的方式，將調(diào)用封裝成任務(wù)并行的執(zhí)行冷溶，縮短總體響應(yīng)時間渐白。另外，使用線程池也是有考量的挂洛，這種場景最重要的就是獲取最大的響應(yīng)速度去滿足用戶礼预，所以應(yīng)該不設(shè)置隊列去緩沖并發(fā)任務(wù)，調(diào)高corePoolSize和maxPoolSize去盡可能創(chuàng)造多的線程快速執(zhí)行任務(wù)虏劲。

圖12 并行執(zhí)行任務(wù)提升任務(wù)響應(yīng)速度

場景2：快速處理批量任務(wù)

描述：離線的大量計算任務(wù)托酸，需要快速執(zhí)行。比如說柒巫，統(tǒng)計某個報表励堡，需要計算出全國各個門店中有哪些商品有某種屬性，用于后續(xù)營銷策略的分析堡掏，那么我們需要查詢?nèi)珖虚T店中的所有商品应结，并且記錄具有某屬性的商品，然后快速生成報表泉唁。

分析：這種場景需要執(zhí)行大量的任務(wù)鹅龄，我們也會希望任務(wù)執(zhí)行的越快越好。這種情況下亭畜，也應(yīng)該使用多線程策略扮休，并行計算。但與響應(yīng)速度優(yōu)先的場景區(qū)別在于拴鸵，這類場景任務(wù)量巨大玷坠，并不需要瞬時的完成蜗搔，而是關(guān)注如何使用有限的資源，盡可能在單位時間內(nèi)處理更多的任務(wù)八堡，也就是吞吐量優(yōu)先的問題樟凄。所以應(yīng)該設(shè)置隊列去緩沖并發(fā)任務(wù)，調(diào)整合適的corePoolSize去設(shè)置處理任務(wù)的線程數(shù)兄渺。在這里缝龄，設(shè)置的線程數(shù)過多可能還會引發(fā)線程上下文切換頻繁的問題，也會降低處理任務(wù)的速度溶耘，降低吞吐量二拐。

圖13 并行執(zhí)行任務(wù)提升批量任務(wù)執(zhí)行速度

3.2 實際問題及方案思考

線程池使用面臨的核心的問題在于：線程池的參數(shù)并不好配置。一方面線程池的運行機(jī)制不是很好理解凳兵，配置合理需要強(qiáng)依賴開發(fā)人員的個人經(jīng)驗和知識百新；另一方面，線程池執(zhí)行的情況和任務(wù)類型相關(guān)性較大庐扫，IO密集型和CPU密集型的任務(wù)運行起來的情況差異非常大饭望，這導(dǎo)致業(yè)界并沒有一些成熟的經(jīng)驗策略幫助開發(fā)人員參考。

關(guān)于線程池配置不合理引發(fā)的故障形庭，公司內(nèi)部有較多記錄铅辞，下面舉一些例子：

Case1：2018年XX頁面展示接口大量調(diào)用降級。

事故描述：XX頁面展示接口產(chǎn)生大量調(diào)用降級萨醒，數(shù)量級在幾十到上百斟珊。

事故原因：該服務(wù)展示接口內(nèi)部邏輯使用線程池做并行計算，由于沒有預(yù)估好調(diào)用的流量富纸，導(dǎo)致最大核心數(shù)設(shè)置偏小囤踩，大量拋出RejectedExecutionException，觸發(fā)接口降級條件晓褪，示意圖如下：

圖14 線程數(shù)核心設(shè)置過小引發(fā)RejectExecutionException

Case2：2018年XX業(yè)務(wù)服務(wù)不可用S2級故障堵漱。

事故描述：XX業(yè)務(wù)提供的服務(wù)執(zhí)行時間過長，作為上游服務(wù)整體超時涣仿，大量下游服務(wù)調(diào)用失敗勤庐。

事故原因：該服務(wù)處理請求內(nèi)部邏輯使用線程池做資源隔離，由于隊列設(shè)置過長好港，最大線程數(shù)設(shè)置失效愉镰，導(dǎo)致請求數(shù)量增加時，大量任務(wù)堆積在隊列中钧汹，任務(wù)執(zhí)行時間過長岛杀，最終導(dǎo)致下游服務(wù)的大量調(diào)用超時失敗。示意圖如下：

圖15 線程池隊列長度設(shè)置過長崭孤、corePoolSize設(shè)置過小導(dǎo)致任務(wù)執(zhí)行速度低

業(yè)務(wù)中要使用線程池类嗤，而使用不當(dāng)又會導(dǎo)致故障，那么我們怎樣才能更好地使用線程池呢辨宠？針對這個問題遗锣，我們下面延展幾個方向：

1. 能否不用線程池?

回到最初的問題，業(yè)務(wù)使用線程池是為了獲取并發(fā)性嗤形，對于獲取并發(fā)性精偿，是否可以有什么其他的方案呢替代？我們嘗試進(jìn)行了一些其他方案的調(diào)研：

綜合考慮赋兵，這些新的方案都能在某種情況下提升并行任務(wù)的性能笔咽，然而本次重點解決的問題是如何更簡易、更安全地獲得的并發(fā)性霹期。另外叶组，Actor模型的應(yīng)用實際上甚少，只在Scala中使用廣泛历造，協(xié)程框架在Java中維護(hù)的也不成熟甩十。這三者現(xiàn)階段都不是足夠的易用，也并不能解決業(yè)務(wù)上現(xiàn)階段的問題吭产。

2. 追求參數(shù)設(shè)置合理性侣监？

有沒有一種計算公式，能夠讓開發(fā)同學(xué)很簡易地計算出某種場景中的線程池應(yīng)該是什么參數(shù)呢臣淤？

帶著這樣的疑問橄霉，我們調(diào)研了業(yè)界的一些線程池參數(shù)配置方案：

調(diào)研了以上業(yè)界方案后，我們并沒有得出通用的線程池計算方式邑蒋。并發(fā)任務(wù)的執(zhí)行情況和任務(wù)類型相關(guān)姓蜂，IO密集型和CPU密集型的任務(wù)運行起來的情況差異非常大，但這種占比是較難合理預(yù)估的寺董，這導(dǎo)致很難有一個簡單有效的通用公式幫我們直接計算出結(jié)果覆糟。

3. 線程池參數(shù)動態(tài)化？

盡管經(jīng)過謹(jǐn)慎的評估遮咖，仍然不能夠保證一次計算出來合適的參數(shù)滩字，那么我們是否可以將修改線程池參數(shù)的成本降下來，這樣至少可以發(fā)生故障的時候可以快速調(diào)整從而縮短故障恢復(fù)的時間呢御吞？基于這個思考麦箍，我們是否可以將線程池的參數(shù)從代碼中遷移到分布式配置中心上，實現(xiàn)線程池參數(shù)可動態(tài)配置和即時生效陶珠，線程池參數(shù)動態(tài)化前后的參數(shù)修改流程對比如下：

圖16 動態(tài)修改線程池參數(shù)新舊流程對比

基于以上三個方向?qū)Ρ刃眩覀兛梢钥闯鰠?shù)動態(tài)化方向簡單有效。

3.3 動態(tài)化線程池

3.3.1 整體設(shè)計

動態(tài)化線程池的核心設(shè)計包括以下三個方面：

簡化線程池配置：線程池構(gòu)造參數(shù)有8個揍诽，但是最核心的是3個：corePoolSize诀蓉、maximumPoolSize栗竖，workQueue，它們最大程度地決定了線程池的任務(wù)分配和線程分配策略渠啤『考慮到在實際應(yīng)用中我們獲取并發(fā)性的場景主要是兩種：（1）并行執(zhí)行子任務(wù)，提高響應(yīng)速度沥曹。這種情況下份名，應(yīng)該使用同步隊列，沒有什么任務(wù)應(yīng)該被緩存下來妓美，而是應(yīng)該立即執(zhí)行僵腺。（2）并行執(zhí)行大批次任務(wù)，提升吞吐量壶栋。這種情況下辰如，應(yīng)該使用有界隊列，使用隊列去緩沖大批量的任務(wù)委刘，隊列容量必須聲明丧没，防止任務(wù)無限制堆積。所以線程池只需要提供這三個關(guān)鍵參數(shù)的配置锡移，并且提供兩種隊列的選擇呕童，就可以滿足絕大多數(shù)的業(yè)務(wù)需求，Less is More淆珊。

參數(shù)可動態(tài)修改：為了解決參數(shù)不好配夺饲，修改參數(shù)成本高等問題。在Java線程池留有高擴(kuò)展性的基礎(chǔ)上施符，封裝線程池往声，允許線程池監(jiān)聽同步外部的消息，根據(jù)消息進(jìn)行修改配置戳吝。將線程池的配置放置在平臺側(cè)浩销，允許開發(fā)同學(xué)簡單的查看、修改線程池配置听哭。

增加線程池監(jiān)控：對某事物缺乏狀態(tài)的觀測慢洋，就對其改進(jìn)無從下手。在線程池執(zhí)行任務(wù)的生命周期添加監(jiān)控能力陆盘，幫助開發(fā)同學(xué)了解線程池狀態(tài)普筹。

圖17 動態(tài)化線程池整體設(shè)計

3.3.2 功能架構(gòu)

動態(tài)化線程池提供如下功能：

動態(tài)調(diào)參：支持線程池參數(shù)動態(tài)調(diào)整、界面化操作隘马；包括修改線程池核心大小太防、最大核心大小、隊列長度等酸员；參數(shù)修改后及時生效蜒车。

任務(wù)監(jiān)控：支持應(yīng)用粒度讳嘱、線程池粒度、任務(wù)粒度的Transaction監(jiān)控醇王；可以看到線程池的任務(wù)執(zhí)行情況呢燥、最大任務(wù)執(zhí)行時間、平均任務(wù)執(zhí)行時間寓娩、95/99線等。

負(fù)載告警：線程池隊列任務(wù)積壓到一定值的時候會通過大象（美團(tuán)內(nèi)部通訊工具）告知應(yīng)用開發(fā)負(fù)責(zé)人呼渣；當(dāng)線程池負(fù)載數(shù)達(dá)到一定閾值的時候會通過大象告知應(yīng)用開發(fā)負(fù)責(zé)人棘伴。

操作監(jiān)控：創(chuàng)建/修改和刪除線程池都會通知到應(yīng)用的開發(fā)負(fù)責(zé)人。

操作日志：可以查看線程池參數(shù)的修改記錄屁置，誰在什么時候修改了線程池參數(shù)焊夸、修改前的參數(shù)值是什么。

權(quán)限校驗：只有應(yīng)用開發(fā)負(fù)責(zé)人才能夠修改應(yīng)用的線程池參數(shù)蓝角。

圖18 動態(tài)化線程池功能架構(gòu)

參數(shù)動態(tài)化

JDK原生線程池ThreadPoolExecutor提供了如下幾個public的setter方法阱穗，如下圖所示：

圖19 JDK 線程池參數(shù)設(shè)置接口

JDK允許線程池使用方通過ThreadPoolExecutor的實例來動態(tài)設(shè)置線程池的核心策略，以setCorePoolSize為方法例使鹅，在運行期線程池使用方調(diào)用此方法設(shè)置corePoolSize之后揪阶，線程池會直接覆蓋原來的corePoolSize值，并且基于當(dāng)前值和原始值的比較結(jié)果采取不同的處理策略患朱。對于當(dāng)前值小于當(dāng)前工作線程數(shù)的情況鲁僚，說明有多余的worker線程，此時會向當(dāng)前idle的worker線程發(fā)起中斷請求以實現(xiàn)回收裁厅，多余的worker在下次idle的時候也會被回收冰沙；對于當(dāng)前值大于原始值且當(dāng)前隊列中有待執(zhí)行任務(wù)，則線程池會創(chuàng)建新的worker線程來執(zhí)行隊列任務(wù)执虹，setCorePoolSize具體流程如下：

圖20 setCorePoolSize方法執(zhí)行流程

線程池內(nèi)部會處理好當(dāng)前狀態(tài)做到平滑修改拓挥，其他幾個方法限于篇幅，這里不一一介紹袋励。重點是基于這幾個public方法侥啤，我們只需要維護(hù)ThreadPoolExecutor的實例，并且在需要修改的時候拿到實例修改其參數(shù)即可插龄≡钙澹基于以上的思路，我們實現(xiàn)了線程池參數(shù)的動態(tài)化均牢、線程池參數(shù)在管理平臺可配置可修改糠雨，其效果圖如下圖所示：

圖21 可動態(tài)修改線程池參數(shù)

用戶可以在管理平臺上通過線程池的名字找到指定的線程池，然后對其參數(shù)進(jìn)行修改徘跪，保存后會實時生效甘邀。目前支持的動態(tài)參數(shù)包括核心數(shù)琅攘、最大值、隊列長度等松邪。除此之外坞琴，在界面中，我們還能看到用戶可以配置是否開啟告警逗抑、隊列等待任務(wù)告警閾值剧辐、活躍度告警等等。關(guān)于監(jiān)控和告警邮府，我們下面一節(jié)會對齊進(jìn)行介紹荧关。

線程池監(jiān)控

除了參數(shù)動態(tài)化之外，為了更好地使用線程池褂傀，我們需要對線程池的運行狀況有感知忍啤，比如當(dāng)前線程池的負(fù)載是怎么樣的膝但？分配的資源夠不夠用书幕？任務(wù)的執(zhí)行情況是怎么樣的陕凹？是長任務(wù)還是短任務(wù)沙兰？

基于對這些問題的思考甚疟，動態(tài)化線程池提供了多個維度的監(jiān)控和告警能力粱年，包括：線程池活躍度矛辕、任務(wù)的執(zhí)行Transaction（頻率酣倾、耗時）煎饼、Reject異常讹挎、線程池內(nèi)部統(tǒng)計信息等等，既能幫助用戶從多個維度分析線程池的使用情況吆玖，又能在出現(xiàn)問題第一時間通知到用戶筒溃，從而避免故障或加速故障恢復(fù)。

1. 負(fù)載監(jiān)控和告警

線程池負(fù)載關(guān)注的核心問題是：基于當(dāng)前線程池參數(shù)分配的資源夠不夠沾乘。對于這個問題怜奖，我們可以從事前和事中兩個角度來看。事前翅阵，線程池定義了“活躍度”這個概念歪玲，來讓用戶在發(fā)生Reject異常之前能夠感知線程池負(fù)載問題，線程池活躍度計算公式為：線程池活躍度 = activeCount/maximumPoolSize掷匠。這個公式代表當(dāng)活躍線程數(shù)趨向于maximumPoolSize的時候滥崩，代表線程負(fù)載趨高。

事中讹语，也可以從兩方面來看線程池的過載判定條件钙皮，一個是發(fā)生了Reject異常，一個是隊列中有等待任務(wù)（支持定制閾值）。以上兩種情況發(fā)生了都會觸發(fā)告警短条，告警信息會通過大象推送給服務(wù)所關(guān)聯(lián)的負(fù)責(zé)人导匣。

圖22 大象告警通知

2. 任務(wù)級精細(xì)化監(jiān)控

在傳統(tǒng)的線程池應(yīng)用場景中，線程池中的任務(wù)執(zhí)行情況對于用戶來說是透明的茸时。比如在一個具體的業(yè)務(wù)場景中贡定，業(yè)務(wù)開發(fā)申請了一個線程池同時用于執(zhí)行兩種任務(wù)，一個是發(fā)消息任務(wù)可都、一個是發(fā)短信任務(wù)缓待，這兩類任務(wù)實際執(zhí)行的頻率和時長對于用戶來說沒有一個直觀的感受，很可能這兩類任務(wù)不適合共享一個線程池汹粤，但是由于用戶無法感知命斧，因此也無從優(yōu)化。動態(tài)化線程池內(nèi)部實現(xiàn)了任務(wù)級別的埋點嘱兼，且允許為不同的業(yè)務(wù)任務(wù)指定具有業(yè)務(wù)含義的名稱，線程池內(nèi)部基于這個名稱做Transaction打點贤徒，基于這個功能芹壕，用戶可以看到線程池內(nèi)部任務(wù)級別的執(zhí)行情況，且區(qū)分業(yè)務(wù)接奈，任務(wù)監(jiān)控示意圖如下圖所示：

圖23 線程池任務(wù)執(zhí)行監(jiān)控

3. 運行時狀態(tài)實時查看

用戶基于JDK原生線程池ThreadPoolExecutor提供的幾個public的getter方法踢涌，可以讀取到當(dāng)前線程池的運行狀態(tài)以及參數(shù)，如下圖所示：

圖24 線程池實時運行情況

動態(tài)化線程池基于這幾個接口封裝了運行時狀態(tài)實時查看的功能序宦，用戶基于這個功能可以了解線程池的實時狀態(tài)睁壁，比如當(dāng)前有多少個工作線程，執(zhí)行了多少個任務(wù)互捌，隊列中等待的任務(wù)數(shù)等等潘明。效果如下圖所示：

圖25 線程池實時運行情況

3.4 實踐總結(jié)

面對業(yè)務(wù)中使用線程池遇到的實際問題，我們曾回到支持并發(fā)性問題本身來思考有沒有取代線程池的方案秕噪，也曾嘗試著去追求線程池參數(shù)設(shè)置的合理性钳降，但面對業(yè)界方案具體落地的復(fù)雜性、可維護(hù)性以及真實運行環(huán)境的不確定性腌巾，我們在前兩個方向上可謂“舉步維艱”遂填。

最終，我們回到線程池參數(shù)動態(tài)化方向上探索澈蝙，得出一個且可以解決業(yè)務(wù)問題的方案吓坚，雖然本質(zhì)上還是沒有逃離使用線程池的范疇，但是在成本和收益之間灯荧，算是取得了一個很好的平衡礁击。成本在于實現(xiàn)動態(tài)化以及監(jiān)控成本不高，收益在于：在不顛覆原有線程池使用方式的基礎(chǔ)之上，從降低線程池參數(shù)修改的成本以及多維度監(jiān)控這兩個方面降低了故障發(fā)生的概率客税。希望本文提供的動態(tài)化線程池思路能對大家有幫助况褪。

源于這個文章設(shè)計思路，做了部分時間更耻。

源碼地址：https://github.com/mushang8923/thread-pool.git

木巴沙