為什麼阿里巴巴要禁用Executors建立執行緒池?
看阿里巴巴開發手冊併發程式設計這塊有一條:執行緒池不允許使用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,執行緒池最大數量為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,執行緒池最大數量為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,new LinkedBlockingQueue<Runnable>());
}
複製程式碼
FixedThreadPool
是固定核心執行緒的執行緒池,固定核心執行緒數由使用者傳入
- corePoolSize => nThreads,核心執行緒池的數量為1
- maximumPoolSize => nThreads,執行緒池最大數量為nThreads,即最多隻可以建立nThreads個執行緒
- 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
密集型,然後分別使用不同的執行緒池去處理,從而使每個執行緒池可以根據各自的工作負載來調整 - 阻塞佇列 => 推薦使用有界佇列,有界佇列有助於避免資源耗盡的情況發生
-
拒絕策略 => 預設採用的是
AbortPolicy
拒絕策略,直接在程式中丟擲RejectedExecutionException
異常【因為是執行時異常,不強制catch
】,這種處理方式不夠優雅。處理拒絕策略有以下幾種比較推薦:- 在程式中捕獲
RejectedExecutionException
異常,在捕獲異常中對任務進行處理。針對預設拒絕策略 - 使用
CallerRunsPolicy
拒絕策略,該策略會將任務交給呼叫execute的執行緒執行【一般為主執行緒】,此時主執行緒將在一段時間內不能提交任何任務,從而使工作執行緒處理正在執行的任務。此時提交的執行緒將被儲存在TCP
佇列中,TCP佇列滿將會影響客戶端,這是一種平緩的效能降低 - 自定義拒絕策略,只需要實現
RejectedExecutionHandler
介面即可 - 如果任務不是特別重要,使用
DiscardPolicy
和DiscardOldestPolicy
拒絕策略將任務丟棄也是可以的
- 在程式中捕獲
如果使用Executors的靜態方法建立ThreadPoolExecutor
物件,可以通過使用Semaphore
對任務的執行進行限流也可以避免出現OOM
異常
由於執行緒池引數定義經驗較少,都是理論知識,歡迎有經驗的大佬補充
每天學習一點點,加油呀,歡迎點贊
附往期文章:歡迎你的閱讀、點贊、評論
設計模式相關:
1. 單例模式,你真的寫對了嗎?
2. (策略模式+工廠模式+map)套餐 Kill 專案中的switch case
JAVA8相關:
1. 使用Stream API優化程式碼
2. 親,建議你使用LocalDateTime而不是Date哦
資料庫相關:
1. mysql資料庫時間型別datetime、bigint、timestamp的查詢效率比較
2. 很高興!終於踩到了慢查詢的坑
日誌相關:
1. 日誌框架,選擇Logback Or Log4j2?
2. Logback配置檔案這麼寫,TPS提高10倍
工程相關:
1. 閒來無事,動手寫一個LRU本地快取
2. Redis實現點贊功能模組
3. JMX視覺化監控執行緒池
4. 許可權管理 【SpringSecurity篇】
5. Spring自定義註解從入門到精通
6. java模擬登陸優酷
7. QPS這麼高,那就來寫個多級快取吧
8. java使用phantomjs進行截圖