什么是線程池

• 是一種基于池化思想管理線程的工具。池化技術：池化技術簡單點來說，就是提前保存大量的資源，以備不時之需。比如我們的對象池，數據庫連接池等。

線程池好處

我們?yōu)槭裁匆褂镁€程池，直接new thread start不好嗎？

• 「降低資源消耗」: 通過重復利用已創(chuàng)建的線程來降低線程創(chuàng)建和銷毀所造成的消耗。
• 「提高響應速度:」??任務到達時，可以立即執(zhí)行，不需要等到線程創(chuàng)建再來執(zhí)行任務。
• 「提高線程的可管理性：」?線程是稀缺資源，如果無限制創(chuàng)建，不僅會消耗系統(tǒng)資源，還會因為線程的不合理分布導致資源調度失衡，降低系統(tǒng)的穩(wěn)定性。使用線程池可以進行統(tǒng)一的分配、調優(yōu)和監(jiān)控。

線程池的執(zhí)行流程

我們先來看看線程池的一個執(zhí)行流程圖，此圖來自文末參考1

通過上述圖我們可以得出線程池執(zhí)行任務可以有以下幾種情況：

• 如果當前的運行線程小于 coreSize ，則創(chuàng)建新線程來執(zhí)行任務。
• 如果當前運行的線程等于 coreSize 或多余 coreSize (動態(tài)修改了 coreSize 才會出現這種情況)，把任務放到阻塞隊列中。
• 如果隊列已滿無法將新加入的任務放進去的話，則需要創(chuàng)建新的線程來執(zhí)行任務。
• 如果新創(chuàng)建線程已經達到了最大線程數，任務將會被拒絕。

怎么用線程池

在java jdk的Executors有提供創(chuàng)建不同線程池的方法(一般不推薦這種做法)阿里巴巴的開發(fā)手冊也明確強制規(guī)定不讓通過Executors來創(chuàng)建的，在一些公司的開發(fā)規(guī)范里面應該也會有這么一條吧。

• newFixedThreadPool
• newSingleThreadExecutor
• newCachedThreadPool
• newScheduledThreadPool
• newWorkStealingPool (jdk1.8新增的) 我們可以使用ThreadPoolExecutor來創(chuàng)建線程池

??public?ThreadPoolExecutor(int?corePoolSize,
??????????????????????????????int?maximumPoolSize,
??????????????????????????????long?keepAliveTime,
??????????????????????????????TimeUnit?unit,
??????????????????????????????BlockingQueue?workQueue,
??????????????????????????????ThreadFactory?threadFactory,
??????????????????????????????RejectedExecutionHandler?handler)?

我們可以看出創(chuàng)建線程池有七個參數，而上述我們通過Executors工具類來創(chuàng)建的線程池就一兩個參數，其他參數它都幫我們默認寫死了，我們只有真正理解了這幾個參數才能更好的去使用線程池。下面我們來看看這七個參數（線程池參數）。

corePoolSize

• 核心線程數（線程池的基本大小）當我們提交一個任務到線程池時就會創(chuàng)建一個線程來執(zhí)行任務.當我們需要執(zhí)行的任務數大于核心線程數了就不再創(chuàng)建， 如果我們調用了 prestartAllCoreThreads()方法線程池就會為我們提前創(chuàng)建好所有的基本線程。

maximumPoolSize

• 最大線程數:線程池允許創(chuàng)建的最大線程數。如果隊列已經滿了，且已創(chuàng)建的線程數小于最大線程數，則線程池就會創(chuàng)建新的線程來執(zhí)行任務。這里有個小知識點，如果我們的隊列是用的無界隊列，這個參數是不會起作用的，因為我們的任務會一直往隊列中加，隊列永遠不會滿（內存允許的情況）。

keepAliveTime

• 空閑線程最大生存時間。當前線程數大于核心線程數時，結束多余的空閑線程等待新任務的最長時間。默認情況下，只有當線程池中的線程數大于 corePoolSize 時， keepAliveTime 才會起作用，直到線程池中的線程數不大于 corePoolSize ，即當線程池中的線程數大于 corePoolSize 時，如果一個線程空閑的時間達到 keepAliveTime ，則會終止，直到線程池中的線程數不超過 corePoolSize 。但是如果調用了 allowCoreThreadTimeOut (boolean)方法，在線程池中的線程數不大于 corePoolSize 時， keepAliveTime 參數也會起作用，直到線程池中的線程數為0；比如當前線程池中最大線程數(maximumPoolSize)為50，核心線程數（corePoolSize）為10，當前正在跑任務的線程數為30.然后是不是空出了20個線程沒活干，所以這20個線程就要被消毀，有點卸磨殺驢的感覺。如果剩下的30個線程干完活了也休息了keepAliveTime這么久，然后這30個線程里面也要被銷毀20個，就保留個核心線程。如果設置了 allowCoreThreadTimeOut 等于 true 核心線程也會被銷毀。就跟我們做外包項目一樣，甲方項目完成了就得去另外一個甲方，如果短時間內都沒有甲方接納你的話，你就要被辭退了，只會留下幾個核心人員維護下項目，如果甲方項目維護的話用自己的人的話，所有的外包人會都會被辭退。

unit

• 線程存活時間的的單位?？蛇x的單位有 days 、 hours 等。

workQueue

任務隊列?？梢赃x擇以下這些隊列

threadFactory

用戶設置創(chuàng)建線程的工廠，我們可以通過這個工廠來創(chuàng)建有業(yè)務意義的線程名字。我們可以對比下自定義的線程工廠和默認的線程工廠創(chuàng)建的名字。

阿里開發(fā)手冊也有明確說到，需要指定有意義的線程名字。

RejectedExecutionHandler

• 線程池拒絕策略。當隊列和線程池都滿了說明線程池已經處于飽和狀態(tài)。必須要采取一定的策略來處理新提交的任務。jdk默認提供了四種拒絕策略： 其實我們也可以自定義任務拒絕策略（實現下 RejectedExecutionHandler 接口），比如說如果任務拒絕了我們可以記錄下日志，或者重試等，根據自己的業(yè)務需求來實現。
• dubbo ?任務拒絕策略

?@Override
???public?void?rejectedExecution(Runnable?r,?ThreadPoolExecutor?e)?{
???????String?msg?=?String.format("Thread?pool?is?EXHAUSTED!"?+
???????????????"?Thread?Name:?%s,?Pool?Size:?%d?(active:?%d,?core:?%d,?max:?%d,?largest:?%d),?Task:?%d?(completed:?"
???????????????+?"%d),"?+
???????????????"?Executor?status:(isShutdown:%s,?isTerminated:%s,?isTerminating:%s),?in?%s://%s:%d!",
???????????threadName,?e.getPoolSize(),?e.getActiveCount(),?e.getCorePoolSize(),?e.getMaximumPoolSize(),
???????????e.getLargestPoolSize(),
???????????e.getTaskCount(),?e.getCompletedTaskCount(),?e.isShutdown(),?e.isTerminated(),?e.isTerminating(),
???????????url.getProtocol(),?url.getIp(),?url.getPort());
???????logger.warn(msg);
???????dumpJStack();
???????dispatchThreadPoolExhaustedEvent(msg);
???????throw?new?RejectedExecutionException(msg);
???}

我們可以看出dubbo的拒絕策略主要記錄了詳細的級別為warm的日志、輸出當前線程堆棧詳情、繼續(xù)拋出拒絕任務異常。

線程池參數如何設置？

線程池既然有這么多參數那么我們如何去根據自己的業(yè)務實際情況來去合理的設置每個參數？

• 一般我們如果任務為耗時 IO 型比如讀取數據庫、文件讀寫以及網略通信的的話這些任務不會占據很多 cpu 的資源但是會比較耗時：線程數設置為2倍CPU數以上，充分的來利用 CPU 資源。
• 一般我們如果任務為CPU密集型的話比如大量計算、解壓、壓縮等這些操作都會占據大量的cpu。所以針對于這種情況的話一般設置線程數為：1倍cpu+1。為啥要加1，很多說法是備份線程。
• 如果既有IO密集型任務，又有 CPU 密集型任務，這種該怎么設置線程大?。窟@種的話最好分開用線程池處理， IO 密集的用 IO 密集型線程池處理， CPU 密集型的用cpu密集型處理。以上都只是理算情況下的估算而已，真正的合理參數還是需要看看實際生產運行的效果來合理的調整的。

監(jiān)控線程池

• 線程池工作是否飽和？線程的情況如何？總共執(zhí)行了多少個任務？現在線程池的運行情況如何？隊列里面是否有堆積任務？面對上面這些問題，線程池也有提供一些方法可以讓我們來查看上面這些指標。 有了這些參數我們是不是調整線程池的參數就更加方便了?；蛘吒鶕€程池的活躍程度我們自動來調節(jié)（動態(tài)調整下篇再來說）線程池的參數。

關于線程池的幾個問題

• 線程池是否區(qū)分核心線程和非核心線程？
• 如何保證核心線程不被銷毀？
• 線程池的線程是如何做到復用的？以上幾個小問題我們去看看線程池的源碼，這幾個問題應該就不成問題了，我們下篇見。