在 JDK1.5 以前，研發(fā)人員在面對(duì)線程頻繁調(diào)度的場景，必須手動(dòng)打造線程池，來節(jié)約系統(tǒng)開銷（畫外音：真是吃了不少苦頭）。

從 JDK1.5 開始，Java 提供了一個(gè) Excutors 工廠類來生產(chǎn)線程池，可以幫助研發(fā)人員有效的進(jìn)行線程控制（畫外音：不用造輪子啦，爽歪歪）。

（配圖釋義：JDK 1.8 能用 Excutors 創(chuàng)建的線程池）

如上圖示意，Excutors 提供了滿足各種場景的線程池創(chuàng)建方式， Java 研發(fā)人員就不用苦逼哈哈的去造輪子啦，誰用誰爽。

但是，阿里開發(fā)規(guī)約明確強(qiáng)制研發(fā)人員：線程池不允許使用 Executors 去創(chuàng)建，而是通過 ThreadPoolExecutor 的方式。

不過，若經(jīng)常關(guān)注源碼的同學(xué)會(huì)發(fā)現(xiàn)，無論是 newFixedThreadPool() 方法、newSingleThreadExecutor() 方法，還是 newCachedThreadPool() 方法，其背后均使用了 ThreadPoolExecutor。

（配圖釋義：JDK 1.8 能用 Excutors 創(chuàng)建的線程池的背后）

通過上面源碼截圖，可以清晰看出，以上幾種創(chuàng)建線程池的方式，均是對(duì) ThreadPoolExecutor 類的封裝，所以要想徹底掌握線程池，勢必要吃透線程池背后的 ThreadPoolExecutor。

 解剖：構(gòu)造函數(shù)  

有關(guān) ThreadPoolExecute 構(gòu)造函數(shù)，很多書上或者文章都會(huì)提到，下面再簡單了解一下每個(gè)參數(shù)的具體含義。

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

構(gòu)造函數(shù)的參數(shù)釋義：

corePoolSize：指定線程池中的線程數(shù)量； 

maximumPoolSize：指定線程池中的最大線程數(shù)量；

keepAliveTime：當(dāng)線程池中線程數(shù)量超過 corePoolSize 時(shí)，空閑線程的存活時(shí)間； 

unit：keepAliveTime 的單位； 

workQueue：任務(wù)隊(duì)列，存放提交尚未被執(zhí)行的任務(wù)； 

threadFactory：線程工廠，用于創(chuàng)建線程，一般用默認(rèn)的即可；

handler：拒絕策略，當(dāng)任務(wù)太多來不及處理，如何拒絕任務(wù)。

以上參數(shù)除了 workQueue 以及 handler 外，大部分都很易懂。接下來重點(diǎn)說說 workQueue 以及 handler 兩個(gè)參數(shù)。

參數(shù) BlockingQueue workQueue，是用于存放提交尚未被執(zhí)行的任務(wù)的隊(duì)列，類型是 BlockingQueue 接口的對(duì)象，用于存放 Runnable 對(duì)象。

參數(shù) RejectedExecutionHandler handler 是指當(dāng)任務(wù)數(shù)量超過系統(tǒng)承載能力時(shí)，該如何處理？其中 JDK 提供了四種拒絕策略。

（配圖釋義：JDK 1.8 內(nèi)置的拒絕策略）

JDK 提供的四種拒絕策略歸納，簡單了解一下。

了解完 ThreadPoolExecutor 類的構(gòu)造函數(shù)，接下來探討一下阿里開發(fā)手冊明確強(qiáng)制的一條使用線程池的規(guī)約。

為了更清晰的認(rèn)識(shí)，不妨走進(jìn)源碼看一看。首先走進(jìn) newFixedThreadPool() 方法的源碼，一探究竟。

如源碼截圖所示，newFixedThreadPool() 方法的實(shí)現(xiàn)，返回一個(gè) corePoolSize 和 maximumPoolSize 大小一樣的，并且使用了 LinkedBlockingQueue 任務(wù)隊(duì)列的線程池。

如上面 LinkedBlockingQueue 的源碼所示，隊(duì)列的默認(rèn)長度為 Integer.MAX_VALUE，那么當(dāng)任務(wù)提交頻繁時(shí)，線程池中的線程處理不過來時(shí)，隊(duì)列可能會(huì)迅速膨脹，從而會(huì)出現(xiàn) OOM。

接著走進(jìn) newSingleThreadExecutor() 方法的源碼，看看有沒有新大陸。

如源碼截圖示意，newSingleThreadExecutor 方法實(shí)現(xiàn)中，corePoolSize 和 maximumPoolSize 設(shè)置的值均為 1，返回一個(gè)單線程的線程池，并且使用 LinkedBlockingQueue 任務(wù)隊(duì)列來存在提交的任務(wù)，與 newFixedThreadPool() 方法一樣，當(dāng)任務(wù)提交頻繁時(shí)，線程池中的線程處理不過來時(shí)，隊(duì)列會(huì)迅速膨脹，從而會(huì)出現(xiàn) OOM。

最后看看 newCachedThreadPool() 方法的源碼實(shí)現(xiàn)，一探究竟。

如上圖源碼示意，newCachedThreadPool() 方法實(shí)現(xiàn)，返回了一個(gè) corePoolSize 為 0，maximumPoolSize 的值為 Integer.MAX_VALUE，并且使用 SynchronousQueue 作為任務(wù)隊(duì)列的線程池。

而 SynchronousQueue 隊(duì)列是一種直接提交的隊(duì)列（不會(huì)保存提交的任務(wù)），所以總會(huì)使線程池增加新的線程來執(zhí)行任務(wù)，當(dāng)任務(wù)執(zhí)行完畢后，由于 corePoolSize 為 0，因此空閑線程又會(huì)在 60 秒內(nèi)被回收。

如果同時(shí)有大量任務(wù)被提交，而任務(wù)的執(zhí)行又不那么快時(shí)，newCachedThreadPool() 方法，便會(huì)開啟大量的線程進(jìn)行處理，這樣可能很快耗盡系統(tǒng)的資源，進(jìn)而導(dǎo)致 OOM。