Java線程池實(shí)現(xiàn)原理及其在美團(tuán)業(yè)務(wù)中的實(shí)踐

　隨著計(jì)算機(jī)行業(yè)的飛速發(fā)展，摩爾定律逐漸失效，多核CPU成為主流。使用多線程并行計(jì)算逐漸成為開發(fā)人員提升服務(wù)器性能的基本武器。J.U.C提供的線程池ThreadPoolExecutor類，幫助開發(fā)人員管理線程并方便地執(zhí)行并行任務(wù)。了解并合理使用線程池，是一個開發(fā)人員必修的基本功。

　　本文開篇簡述線程池概念和用途，接著結(jié)合線程池的源碼，幫助讀者領(lǐng)略線程池的設(shè)計(jì)思路，最后回歸實(shí)踐，通過案例講述使用線程池遇到的問題，并給出了一種動態(tài)化線程池解決方案。

　　一、寫在前面

　　1.1 線程池是什么

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

　　線程過多會帶來額外的開銷，其中包括創(chuàng)建銷毀線程的開銷、調(diào)度線程的開銷等等，同時也降低了計(jì)算機(jī)的整體性能。線程池維護(hù)多個線程，等待監(jiān)督管理者分配可并發(fā)執(zhí)行的任務(wù)。這種做法，一方面避免了處理任務(wù)時創(chuàng)建銷毀線程開銷的代價(jià)，另一方面避免了線程數(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)資源，還會因?yàn)榫€程的不合理分布導(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)險(xiǎn)。

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

　　為解決資源分配這個問題，線程池采用了“池化”(Pooling)思想。池化，顧名思義，是為了最大化收益并最小化風(fēng)險(xiǎn)，而將資源統(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ì)算機(jī)領(lǐng)域，在金融、設(shè)備、人員管理、工作管理等領(lǐng)域也有相關(guān)的應(yīng)用。

　　在計(jì)算機(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)的開銷。

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

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

　　二、線程池核心設(shè)計(jì)與實(shí)現(xiàn)

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

　　2.1 總體設(shè)計(jì)

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

　　圖1 ThreadPoolExecutor UML類圖

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

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

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

　　圖2 ThreadPoolExecutor運(yùn)行流程

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

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

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

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

　　線程池如何管理線程。

　　2.2 生命周期管理

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

　　private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

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

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

　　private static int runStateOf(int c) { return c & ~CAPACITY; } //計(jì)算當(dāng)前運(yùn)行狀態(tài)

　　private static int workerCountOf(int c) { return c & CAPACITY; } //計(jì)算當(dāng)前線程數(shù)量

　　private static int ctlOf(int rs, int wc) { return rs | wc; } //通過狀態(tài)和線程數(shù)生成ctl

　　ThreadPoolExecutor的運(yùn)行狀態(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)于了解了線程池的核心運(yùn)行機(jī)制。

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

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

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

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

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

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

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

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

　　2.3.2 任務(wù)緩沖

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

　　阻塞隊(duì)列(BlockingQueue)是一個支持兩個附加操作的隊(duì)列。這兩個附加的操作是：在隊(duì)列為空時，獲取元素的線程會等待隊(duì)列變?yōu)榉强?。?dāng)隊(duì)列滿時，存儲元素的線程會等待隊(duì)列可用。阻塞隊(duì)列常用于生產(chǎn)者和消費(fèi)者的場景，生產(chǎn)者是往隊(duì)列里添加元素的線程，消費(fèi)者是從隊(duì)列里拿元素的線程。阻塞隊(duì)列就是生產(chǎn)者存放元素的容器，而消費(fèi)者也只從容器里拿元素。

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

　　圖5 阻塞隊(duì)列

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

　　2.3.3 任務(wù)申請

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

　　線程需要從任務(wù)緩存模塊中不斷地取任務(wù)執(zhí)行，幫助線程從阻塞隊(duì)列中獲取任務(wù)，實(shí)現(xiàn)線程管理模塊和任務(wù)管理模塊之間的通信。這部分策略由getTask方法實(shí)現(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ù)緩存隊(duì)列已滿，并且線程池中的線程數(shù)目達(dá)到maximumPoolSize時，就需要拒絕掉該任務(wù)，采取任務(wù)拒絕策略，保護(hù)線程池。

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

　　public interface RejectedExecutionHandler {

　　void rejectedExecution(Runnable r, ThreadPoolExecutor executor);

　　}

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

　　2.4 Worker線程管理

　　2.4.1 Worker線程

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

　　private final class Worker extends AbstractQueuedSynchronizer implements Runnable{

　　final Thread thread;//Worker持有的線程

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

　　}

　　Worker這個工作線程，實(shí)現(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ù)

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

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

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

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

　　如果該線程現(xiàn)在不是獨(dú)占鎖的狀態(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方法，該方法的功能就是增加一個線程，該方法不考慮線程池是在哪個階段增加的該線程，這個分配線程的策略是在上個步驟完成的，該步驟僅僅完成增加線程，并使它運(yùn)行，最后返回是否成功這個結(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 線程銷毀流程

　　事實(shí)上，在這個方法中，將線程引用移出線程池就已經(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()方法從阻塞隊(duì)列中取任務(wù)。

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

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

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

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

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

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

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

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

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

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

　　分析：從用戶體驗(yàn)角度看，這個結(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è)置隊(duì)列去緩沖并發(fā)任務(wù)，調(diào)高corePoolSize和maxPoolSize去盡可能創(chuàng)造多的線程快速執(zhí)行任務(wù)。

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

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

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

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

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

　　3.2 實(shí)際問題及方案思考

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

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

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

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

　　事故原因：該服務(wù)展示接口內(nèi)部邏輯使用線程池做并行計(jì)算，由于沒有預(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)部邏輯使用線程池做資源隔離，由于隊(duì)列設(shè)置過長，最大線程數(shù)設(shè)置失效，導(dǎo)致請求數(shù)量增加時，大量任務(wù)堆積在隊(duì)列中，任務(wù)執(zhí)行時間過長，最終導(dǎo)致下游服務(wù)的大量調(diào)用超時失敗。示意圖如下：

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

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

　　1. 能否不用線程池?

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

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

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

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

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

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

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

　　盡管經(jīng)過謹(jǐn)慎的評估，仍然不能夠保證一次計(jì)算出來合適的參數(shù)，那么我們是否可以將修改線程池參數(shù)的成本降下來，這樣至少可以發(fā)生故障的時候可以快速調(diào)整從而縮短故障恢復(fù)的時間呢?基于這個思考，我們是否可以將線程池的參數(shù)從代碼中遷移到分布式配置中心上，實(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è)計(jì)

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

　　簡化線程池配置：線程池構(gòu)造參數(shù)有8個，但是最核心的是3個：corePoolSize、maximumPoolSize，workQueue，它們最大程度地決定了線程池的任務(wù)分配和線程分配策略?？紤]到在實(shí)際應(yīng)用中我們獲取并發(fā)性的場景主要是兩種：(1)并行執(zhí)行子任務(wù)，提高響應(yīng)速度。這種情況下，應(yīng)該使用同步隊(duì)列，沒有什么任務(wù)應(yīng)該被緩存下來，而是應(yīng)該立即執(zhí)行。(2)并行執(zhí)行大批次任務(wù)，提升吞吐量。這種情況下，應(yīng)該使用有界隊(duì)列，使用隊(duì)列去緩沖大批量的任務(wù)，隊(duì)列容量必須聲明，防止任務(wù)無限制堆積。所以線程池只需要提供這三個關(guān)鍵參數(shù)的配置，并且提供兩種隊(duì)列的選擇，就可以滿足絕大多數(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è)計(jì)

　　3.3.2 功能架構(gòu)

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

　　動態(tài)調(diào)參：支持線程池參數(shù)動態(tài)調(diào)整、界面化操作;包括修改線程池核心大小、最大核心大小、隊(duì)列長度等;參數(shù)修改后及時生效。

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

　　負(fù)載告警：線程池隊(duì)列任務(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à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的實(shí)例來動態(tài)設(shè)置線程池的核心策略，以setCorePoolSize為方法例，在運(yùn)行期線程池使用方調(diào)用此方法設(shè)置corePoolSize之后，線程池會直接覆蓋原來的corePoolSize值，并且基于當(dāng)前值和原始值的比較結(jié)果采取不同的處理策略。對于當(dāng)前值小于當(dāng)前工作線程數(shù)的情況，說明有多余的worker線程，此時會向當(dāng)前idle的worker線程發(fā)起中斷請求以實(shí)現(xiàn)回收，多余的worker在下次idle的時候也會被回收;對于當(dāng)前值大于原始值且當(dāng)前隊(duì)列中有待執(zhí)行任務(wù)，則線程池會創(chuàng)建新的worker線程來執(zhí)行隊(duì)列任務(wù)，setCorePoolSize具體流程如下：

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

　　線程池內(nèi)部會處理好當(dāng)前狀態(tài)做到平滑修改，其他幾個方法限于篇幅，這里不一一介紹。重點(diǎn)是基于這幾個public方法，我們只需要維護(hù)ThreadPoolExecutor的實(shí)例，并且在需要修改的時候拿到實(shí)例修改其參數(shù)即可?；谝陨系乃悸罚覀儗?shí)現(xiàn)了線程池參數(shù)的動態(tài)化、線程池參數(shù)在管理平臺可配置可修改，其效果圖如下圖所示：

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

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

　　線程池監(jiān)控

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

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

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

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

　　事中，也可以從兩方面來看線程池的過載判定條件，一個是發(fā)生了Reject異常，一個是隊(duì)列中有等待任務(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ù)實(shí)際執(zhí)行的頻率和時長對于用戶來說沒有一個直觀的感受，很可能這兩類任務(wù)不適合共享一個線程池，但是由于用戶無法感知，因此也無從優(yōu)化。動態(tài)化線程池內(nèi)部實(shí)現(xiàn)了任務(wù)級別的埋點(diǎn)，且允許為不同的業(yè)務(wù)任務(wù)指定具有業(yè)務(wù)含義的名稱，線程池內(nèi)部基于這個名稱做Transaction打點(diǎn)，基于這個功能，用戶可以看到線程池內(nèi)部任務(wù)級別的執(zhí)行情況，且區(qū)分業(yè)務(wù)，任務(wù)監(jiān)控示意圖如下圖所示：

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

　　3. 運(yùn)行時狀態(tài)實(shí)時查看

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

　　圖24 線程池實(shí)時運(yùn)行情況

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

　　圖25 線程池實(shí)時運(yùn)行情況

　　3.4 實(shí)踐總結(jié)

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

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

　　四、參考資料

　　[1]JDK 1.8 源碼

　　[2] 維基百科-線程池

　　[3] 更好的使用Java線程池

　　[4] 維基百科Pooling(Resource Management)

　　[5] 深入理解Java線程池：ThreadPoolExecutor

　　[6]《Java并發(fā)編程實(shí)踐》

　　五、作者簡介

　　致遠(yuǎn)，2018年加入美團(tuán)點(diǎn)評，美團(tuán)到店綜合研發(fā)中心后臺開發(fā)工程師。

　　陸晨，2015年加入美團(tuán)點(diǎn)評，美團(tuán)到店綜合研發(fā)中心后臺技術(shù)專家。

　　 沈陽人流價(jià)格http://mobile.syjk120.cn/