阿里巴巴爲何要禁用 Executors 建立線程池？

做者：何甜甜在嗎
www.juejin.im/post/5dc41c165188257bad4d9e69

看阿里巴巴開發手冊併發編程這塊有一條：線程池不容許使用 Executors 去建立，而是經過ThreadPoolExecutor的方式，經過源碼分析禁用的緣由。

寫在前面

首先感謝你們在蓋樓的間隙閱讀本篇文章，經過閱讀本篇文章你將瞭解到：

• 線程池的定義

• Executors建立線程池的幾種方式

• ThreadPoolExecutor對象

• 線程池執行任務邏輯和線程池參數的關係

• Executors建立返回ThreadPoolExecutor對象

• OOM異常測試

• 如何定義線程池參數

若是隻想知道緣由能夠直接拉到總結那。

線程池的定義

管理一組工做線程。經過線程池複用線程有如下幾點優勢：

• 減小資源建立 => 減小內存開銷，建立線程佔用內存

• 下降系統開銷 => 建立線程須要時間，會延遲處理的請求

• 提升穩定穩定性 => 避免無限建立線程引發的OutOfMemoryError【簡稱OOM】

Executors建立線程池的方式

根據返回的對象類型建立線程池能夠分爲三類：

• 建立返回ThreadPoolExecutor對象

• 建立返回ScheduleThreadPoolExecutor對象

• 建立返回ForkJoinPool對象

本文只討論建立返回ThreadPoolExecutor對象

ThreadPoolExecutor對象

在介紹Executors建立線程池方法前先介紹一下ThreadPoolExecutor，由於這些建立線程池的靜態方法都是返回ThreadPoolExecutor對象，和咱們手動建立ThreadPoolExecutor對象的區別就是咱們不須要本身傳構造函數的參數。

ThreadPoolExecutor的構造函數共有四個，但最終調用的都是同一個：

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

構造函數參數說明：

• corePoolSize => 線程池核心線程數量

• maximumPoolSize => 線程池最大數量

• keepAliveTime => 空閒線程存活時間

• unit => 時間單位

• workQueue => 線程池所使用的緩衝隊列

• threadFactory => 線程池建立線程使用的工廠

• handler => 線程池對拒絕任務的處理策略

線程池執行任務邏輯和線程池參數的關係

執行邏輯說明：

• 判斷核心線程數是否已滿，核心線程數大小和corePoolSize參數有關，未滿則建立線程執行任務

• 若核心線程池已滿，判斷隊列是否滿，隊列是否滿和workQueue參數有關，若未滿則加入隊列中

• 若隊列已滿，判斷線程池是否已滿，線程池是否已滿和maximumPoolSize參數有關，若未滿建立線程執行任務

• 若線程池已滿，則採用拒絕策略處理沒法執執行的任務，拒絕策略和handler參數有關

Executors建立返回ThreadPoolExecutor對象

Executors建立返回ThreadPoolExecutor對象的方法共有三種：

• Executors#newCachedThreadPool => 建立可緩存的線程池

• Executors#newSingleThreadExecutor => 建立單線程的線程池

• Executors#newFixedThreadPool => 建立固定長度的線程池

Executors#newCachedThreadPool方法

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

CachedThreadPool是一個根據須要建立新線程的線程池

• corePoolSize => 0，核心線程池的數量爲0

• maximumPoolSize => Integer.MAX_VALUE，能夠認爲最大線程數是無限的

• keepAliveTime => 60L

• unit => 秒

• workQueue => SynchronousQueue

當一個任務提交時，corePoolSize爲0不建立核心線程，SynchronousQueue是一個不存儲元素的隊列，能夠理解爲隊裏永遠是滿的，所以最終會建立非核心線程來執行任務。對於非核心線程空閒60s時將被回收。

由於Integer.MAX_VALUE很是大，能夠認爲是能夠無限建立線程的，在資源有限的狀況下容易引發OOM異常

Executors#newSingleThreadExecutor方法

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1, 1,
                                0L, TimeUnit.MILLISECONDS,
                                new LinkedBlockingQueue<Runnable>()));
}

SingleThreadExecutor是單線程線程池，只有一個核心線程

• corePoolSize => 1，核心線程池的數量爲1

• maximumPoolSize => 1，只能夠建立一個非核心線程

• keepAliveTime => 0L

• unit => 毫秒

• workQueue => LinkedBlockingQueue

當一個任務提交時，首先會建立一個核心線程來執行任務，若是超過核心線程的數量，將會放入隊列中，由於LinkedBlockingQueue是長度爲Integer.MAX_VALUE的隊列，能夠認爲是無界隊列，所以往隊列中能夠插入無限多的任務，在資源有限的時候容易引發OOM異常，同時由於無界隊列，maximumPoolSize和keepAliveTime參數將無效，壓根就不會建立非核心線程。

Executors#newFixedThreadPool方法

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

FixedThreadPool是固定核心線程的線程池，固定核心線程數由用戶傳入

• corePoolSize => 1，核心線程池的數量爲1

• maximumPoolSize => 1，只能夠建立一個非核心線程

• keepAliveTime => 0L

• unit => 毫秒

• workQueue => LinkedBlockingQueue

• 它和SingleThreadExecutor相似，惟一的區別就是核心線程數不一樣，而且因爲使用的是LinkedBlockingQueue，在資源有限的時候容易引發OOM異常

總結：

FixedThreadPool和SingleThreadExecutor => 容許的請求隊列長度爲Integer.MAX_VALUE，可能會堆積大量的請求，從而引發OOM異常

CachedThreadPool => 容許建立的線程數爲Integer.MAX_VALUE，可能會建立大量的線程，從而引發OOM異常

這就是爲何禁止使用Executors去建立線程池，而是推薦本身去建立ThreadPoolExecutor的緣由

OOM異常測試

理論上會出現OOM異常，必須測試一波驗證以前的說法：

測試類：TaskTest.java

public class TaskTest {
    public static void main(String[] args) {
        ExecutorService es = Executors.newCachedThreadPool();
        int i = 0;
        while (true) {
            es.submit(new Task(i++));
        }
    }
}

使用Executors建立的CachedThreadPool，往線程池中無限添加線程在啓動測試類以前先將JVM內存調整小一點，否則很容易將電腦跑出問題【別問我爲何知道，是鐵憨憨甜沒錯了！！！】，在idea裏：Run -> Edit Configurations

JVM參數說明：

• -Xms10M => Java Heap內存初始化值

• -Xmx10M => Java Heap內存最大值

運行結果：

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
Disconnected from the target VM, address: '127.0.0.1:60416', transport: 'socket'

建立到3w多個線程的時候開始報 OOM 錯誤

另外兩個線程池就不作測試了，測試方法一致，只是建立的線程池不同

如何定義線程池參數

CPU密集型 => 線程池的大小推薦爲CPU數量 + 1，CPU數量能夠根據Runtime.availableProcessors方法獲取

IO密集型 => CPU數量 * CPU利用率 * (1 + 線程等待時間/線程CPU時間)，CPU密集型、IO密集型，看下這篇。

混合型 => 將任務分爲CPU密集型和IO密集型，而後分別使用不一樣的線程池去處理，從而使每一個線程池能夠根據各自的工做負載來調整

阻塞隊列 => 推薦使用有界隊列，有界隊列有助於避免資源耗盡的狀況發生

拒絕策略 => 默認採用的是AbortPolicy拒絕策略，直接在程序中拋出RejectedExecutionException異常【由於是運行時異常，不強制catch】，這種處理方式不夠優雅。線程池 8 大拒絕策略，這篇很全。

處理拒絕策略有如下幾種比較推薦：

• 在程序中捕獲RejectedExecutionException異常，在捕獲異常中對任務進行處理。針對默認拒絕策略

• 使用CallerRunsPolicy拒絕策略，該策略會將任務交給調用execute的線程執行【通常爲主線程】，此時主線程將在一段時間內不能提交任何任務，從而使工做線程處理正在執行的任務。此時提交的線程將被保存在TCP隊列中，TCP隊列滿將會影響客戶端，這是一種平緩的性能下降

• 自定義拒絕策略，只須要實現RejectedExecutionHandler接口便可

• 若是任務不是特別重要，使用DiscardPolicy和DiscardOldestPolicy拒絕策略將任務丟棄也是能夠的

若是使用Executors的靜態方法建立ThreadPoolExecutor對象，能夠經過使用Semaphore對任務的執行進行限流也能夠避免出現OOM異常。

推薦去個人博客閱讀更多：

1.Java JVM、集合、多線程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、後端、架構、阿里巴巴等大廠最新面試題

以爲不錯，別忘了點贊+轉發哦！