為什麼阿里巴巴要禁用 Executors 建立執行緒池?
一. 執行緒池的定義
管理一組工作執行緒。通過執行緒池複用執行緒有以下幾點優點:
-
減少資源建立 => 減少記憶體開銷,建立執行緒佔用記憶體
-
降低系統開銷 => 建立執行緒需要時間,會延遲處理的請求
-
提高穩定穩定性 => 避免無限建立執行緒引起的OutOfMemoryError【簡稱OOM】
二. Executors建立執行緒池的幾種方式
根據返回的物件型別建立執行緒池可以分為三類:
-
建立返回ThreadPoolExecutor物件
-
建立返回ScheduleThreadPoolExecutor物件
-
建立返回ForkJoinPool物件
這裡只討論建立返回ThreadPoolExecutor物件
三. ThreadPoolExecutor物件
ThreadPoolExecutor的建構函式共有四個,但最終呼叫的都是同一個:
1 public ThreadPoolExecutor(int corePoolSize, 2 int maximumPoolSize, 3 longkeepAliveTime, 4 TimeUnit unit, 5 BlockingQueue<Runnable> workQueue, 6 ThreadFactory threadFactory, 7 RejectedExecutionHandler handler)
建構函式引數說明:
-
corePoolSize => 執行緒池核心執行緒數量
-
-
keepAliveTime => 空閒執行緒存活時間
-
unit => 時間單位
-
workQueue => 執行緒池所使用的緩衝佇列
-
threadFactory => 執行緒池建立執行緒使用的工廠
-
handler => 執行緒池對拒絕任務的處理策略
四. 執行緒池執行任務邏輯和執行緒池引數的關係
執行邏輯說明:
-
判斷核心執行緒數是否已滿,核心執行緒數大小和corePoolSize引數有關,未滿則建立執行緒執行任務
-
若核心執行緒池已滿,判斷佇列是否滿,佇列是否滿和workQueue引數有關,若未滿則加入佇列中
-
若佇列已滿,判斷執行緒池是否已滿,執行緒池是否已滿和maximumPoolSize引數有關,若未滿建立執行緒執行任務
-
若執行緒池已滿,則採用拒絕策略處理無法執執行的任務,拒絕策略和handler引數有關
五. Executors建立返回ThreadPoolExecutor物件
Executors建立返回ThreadPoolExecutor物件的方法共有三種:
-
Executors#newCachedThreadPool => 建立可快取的執行緒池
-
Executors#newSingleThreadExecutor => 建立單執行緒的執行緒池
-
Executors#newFixedThreadPool => 建立固定長度的執行緒池
Executors#newCachedThreadPool方法:
1 public static ExecutorService newCachedThreadPool() { 2 return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 3 60L, TimeUnit.SECONDS, 4 new SynchronousQueue<Runnable>()); 5 }
CachedThreadPool是一個根據需要建立新執行緒的執行緒池
-
corePoolSize => 0,核心執行緒池的數量為0
-
-
keepAliveTime => 60L
-
unit => 秒
-
workQueue => SynchronousQueue
當一個任務提交時,corePoolSize為0不建立核心執行緒,SynchronousQueue是一個不儲存元素的佇列,可以理解為隊裡永遠是滿的,因此最終會建立非核心執行緒來執行任務。對於非核心執行緒空閒60s時將被回收。因為Integer.MAX_VALUE非常大,可以認為是可以無限建立執行緒的,在資源有限的情況下容易引起OOM異常
Executors#newSingleThreadExecutor方法
public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 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是固定核心執行緒的執行緒池,固定核心執行緒數由使用者傳入
-
-
maximumPoolSize => 1,只可以建立一個非核心執行緒
-
keepAliveTime => 0L
-
unit => 毫秒
-
workQueue => LinkedBlockingQueue
-
它和SingleThreadExecutor類似,唯一的區別就是核心執行緒數不同,並且由於使用的是LinkedBlockingQueue,在資源有限的時候容易引起OOM異常
總結:
FixedThreadPool和SingleThreadExecutor => 允許的請求佇列長度為Integer.MAX_VALUE,可能會堆積大量的請求,從而引起OOM異常
CachedThreadPool => 允許建立的執行緒數為Integer.MAX_VALUE,可能會建立大量的執行緒,從而引起OOM異常
這就是為什麼禁止使用Executors去建立執行緒池,而是推薦自己去建立ThreadPoolExecutor的原因
六. 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異常。