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

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

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

如上圖示意，Excutors 提供了滿足各種場(chǎng)景的線程池創(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 類的封裝，所以要想徹底掌握線程池，勢(shì)必要吃透線程池背后的 ThreadPoolExecutor。

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

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

public ThreadPoolExecutor(int corePoolSize,                              int maximumPoolSize,                              long keepAliveTime,                              TimeUnit unit,                              BlockingQueue<Runnable> 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<Runnable> 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 提供的四種拒絕策略歸納，簡(jiǎn)單了解一下。

了解完 ThreadPoolExecutor 類的構(gòu)造函數(shù)，接下來探討一下阿里開發(fā)手冊(cè)明確強(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)長(zhǎng)度為 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。