看阿里巴巴開發手冊併發程式設計這塊有一條：執行緒池不允許使用Executors去建立，而是通過ThreadPoolExecutor的方式，通過原始碼分析禁用的原因。

執行緒池的優點

管理一組工作執行緒，通過執行緒池複用執行緒有以下幾點優點：

• 減少資源建立：減少記憶體開銷，建立執行緒佔用記憶體
• 降低系統開銷：建立執行緒需要時間，會延遲處理的請求
• 提高穩定性：避免無限建立執行緒引起的OutOfMemoryError

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建立返回ThreadPoolExecutors物件

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 => nThreads，核心執行緒池的數量為nThreads

• maximumPoolSize => nThreads，可以建立nThreads個非核心執行緒

• keepAliveTime => 0L

• unit => 毫秒

• workQueue => LinkedBlockingQueue

  它和SingleThreadExecutor類似，由於使用的是LinkedBlockingQueue，在資源有限的時候容易引起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密集型，然後分別使用不同的執行緒池去處理，從而使每個執行緒池可以根據各自的工作負載來調整

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

拒絕策略 => 預設採用的是AbortPolicy拒絕策略，直接在程式中丟擲RejectedExecutionException異常【因為是執行時異常，不強制catch】，這種處理方式不夠優雅。處理拒絕策略有以下幾種比較推薦：

• 在程式中捕獲RejectedExecutionException異常，在捕獲異常中對任務進行處理。針對預設拒絕策略
• 使用CallerRunsPolicy拒絕策略，該策略會將任務交給呼叫execute的執行緒執行【一般為主執行緒】，此時主執行緒將在一段時間內不能提交任何任務，從而使工作執行緒處理正在執行的任務。此時提交的執行緒將被儲存在TCP佇列中，TCP佇列滿將會影響客戶端，這是一種平緩的效能降低
• 自定義拒絕策略，只需要實現RejectedExecutionHandler介面即可
• 如果任務不是特別重要，使用DiscardPolicy和DiscardOldestPolicy拒絕策略將任務丟棄也是可以的

如果使用Executors的靜態方法建立ThreadPoolExecutor物件，可以通過使用Semaphore對任務的執行進行限流也可以避免出現OOM異常