淺談為什么阿里巴巴要禁用Executors創(chuàng)建線程池
看阿里巴巴開發(fā)手冊并發(fā)編程這塊有一條:線程池不允許使用Executors去創(chuàng)建,而是通過ThreadPoolExecutor的方式,通過源碼分析禁用的原因
寫在前面
首先感謝大家在蓋樓的間隙閱讀本篇文章,通過閱讀本篇文章你將了解到:
- 線程池的定義
- Executors創(chuàng)建線程池的幾種方式
- ThreadPoolExecutor對象
- 線程池執(zhí)行任務邏輯和線程池參數(shù)的關系
- Executors創(chuàng)建返回ThreadPoolExecutor對象
- OOM異常測試
- 如何定義線程池參數(shù)
如果只想知道原因可以直接拉到總結那
線程池的定義
管理一組工作線程。通過線程池復用線程有以下幾點優(yōu)點:
- 減少資源創(chuàng)建 => 減少內(nèi)存開銷,創(chuàng)建線程占用內(nèi)存
- 降低系統(tǒng)開銷 => 創(chuàng)建線程需要時間,會延遲處理的請求
- 提高穩(wěn)定穩(wěn)定性 => 避免無限創(chuàng)建線程引起的OutOfMemoryError【簡稱OOM】
Executors創(chuàng)建線程池的方式
根據(jù)返回的對象類型創(chuàng)建線程池可以分為三類:
- 創(chuàng)建返回ThreadPoolExecutor對象
- 創(chuàng)建返回ScheduleThreadPoolExecutor對象
- 創(chuàng)建返回ForkJoinPool對象
本文只討論創(chuàng)建返回 ThreadPoolExecutor 對象
ThreadPoolExecutor對象
在介紹 Executors 創(chuàng)建線程池方法前先介紹一下 ThreadPoolExecutor ,因為這些創(chuàng)建線程池的靜態(tài)方法都是返回 ThreadPoolExecutor 對象,和我們手動創(chuàng)建 ThreadPoolExecutor 對象的區(qū)別就是我們不需要自己傳構造函數(shù)的參數(shù)。 ThreadPoolExecutor 的構造函數(shù)共有四個,但最終調(diào)用的都是同一個:
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
構造函數(shù)參數(shù)說明:
- corePoolSize => 線程池核心線程數(shù)量
- maximumPoolSize => 線程池最大數(shù)量
- keepAliveTime => 空閑線程存活時間
- unit => 時間單位
- workQueue => 線程池所使用的緩沖隊列
- threadFactory => 線程池創(chuàng)建線程使用的工廠
- handler => 線程池對拒絕任務的處理策略
線程池執(zhí)行任務邏輯和線程池參數(shù)的關系

執(zhí)行邏輯說明:
- 判斷核心線程數(shù)是否已滿,核心線程數(shù)大小和corePoolSize參數(shù)有關,未滿則創(chuàng)建線程執(zhí)行任務
- 若核心線程池已滿,判斷隊列是否滿,隊列是否滿和workQueue參數(shù)有關,若未滿則加入隊列中
- 若隊列已滿,判斷線程池是否已滿,線程池是否已滿和maximumPoolSize參數(shù)有關,若未滿創(chuàng)建線程執(zhí)行任務
- 若線程池已滿,則采用拒絕策略處理無法執(zhí)執(zhí)行的任務,拒絕策略和handler參數(shù)有關
Executors創(chuàng)建返回ThreadPoolExecutor對象
Executors 創(chuàng)建返回ThreadPoolExecutor對象的方法共有三種:
- Executors#newCachedThreadPool => 創(chuàng)建可緩存的線程池
- Executors#newSingleThreadExecutor => 創(chuàng)建單線程的線程池
- Executors#newFixedThreadPool => 創(chuàng)建固定長度的線程池
Executors#newCachedThreadPool方法
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
CachedThreadPool 是一個根據(jù)需要創(chuàng)建新線程的線程池
- corePoolSize => 0,核心線程池的數(shù)量為0
- maximumPoolSize => Integer.MAX_VALUE,線程池最大數(shù)量為Integer.MAX_VALUE,可以認為可以無限創(chuàng)建線程
- keepAliveTime => 60L
- unit => 秒
- workQueue => SynchronousQueue
當一個任務提交時, corePoolSize 為0不創(chuàng)建核心線程, SynchronousQueue 是一個不存儲元素的隊列,可以理解為隊里永遠是滿的,因此最終會創(chuàng)建非核心線程來執(zhí)行任務。對于非核心線程空閑60s時將被回收。 因為 Integer.MAX_VALUE 非常大,可以認為是可以無限創(chuàng)建線程的,在資源有限的情況下容易引起OOM異常
Executors#newSingleThreadExecutor方法
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
SingleThreadExecutor 是單線程線程池,只有一個核心線程
- corePoolSize => 1,核心線程池的數(shù)量為1
- maximumPoolSize => 1,線程池最大數(shù)量為1,即最多只可以創(chuàng)建一個線程,唯一的線程就是核心線程
- keepAliveTime => 0L
- unit => 毫秒
- workQueue => LinkedBlockingQueue
當一個任務提交時,首先會創(chuàng)建一個核心線程來執(zhí)行任務,如果超過核心線程的數(shù)量,將會放入隊列中, 因為 LinkedBlockingQueue 是長度為 Integer.MAX_VALUE 的隊列,可以認為是無界隊列,因此往隊列中可以插入無限多的任務,在資源有限的時候容易引起 OOM 異常 ,同時因為無界隊列, maximumPoolSize 和 keepAliveTime 參數(shù)將無效,壓根就不會創(chuàng)建非核心線程
Executors#newFixedThreadPool方法
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
FixedThreadPool 是固定核心線程的線程池,固定核心線程數(shù)由用戶傳入
corePoolSize => 1,核心線程池的數(shù)量為1 maximumPoolSize => 1,只可以創(chuàng)建一個非核心線程 keepAliveTime => 0L unit => 秒 workQueue => LinkedBlockingQueue 它和 SingleThreadExecutor 類似,唯一的區(qū)別就是核心線程數(shù)不同,并且由于 使用的是 LinkedBlockingQueue ,在資源有限的時候容易引起 OOM 異常
總結:
- corePoolSize => nThreads,核心線程池的數(shù)量為1
- maximumPoolSize => nThreads,線程池最大數(shù)量為nThreads,即最多只可以創(chuàng)建nThreads個線程
- keepAliveTime => 0L
- unit => 毫秒
- workQueue => LinkedBlockingQueue
- 它和SingleThreadExecutor類似,唯一的區(qū)別就是核心線程數(shù)不同,并且由于使用的是LinkedBlockingQueue,在資源有限的時候容易引起OOM異常
這就是為什么禁止使用 Executors 去創(chuàng)建線程池,而是推薦自己去創(chuàng)建 ThreadPoolExecutor 的原因
OOM異常測試
理論上會出現(xiàn) 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 創(chuàng)建的 CachedThreadPool ,往線程池中無限添加線程 在啟動測試類之前先將 JVM 內(nèi)存調(diào)整小一點,不然很容易將電腦跑出問題【別問我為什么知道,是鐵憨憨甜沒錯了?。?!】,在 idea 里: Run -> Edit Configurations
JVM
參數(shù)說明:
- -Xms10M => Java Heap內(nèi)存初始化值
- -Xmx10M => Java Heap內(nèi)存最大值
運行結果:
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"
Disconnected from the target VM, address: '127.0.0.1:60416', transport: 'socket'
創(chuàng)建到3w多個線程的時候開始報 OOM 錯誤
另外兩個線程池就不做測試了,測試方法一致,只是創(chuàng)建的線程池不一樣
如何定義線程池參數(shù)
- CPU密集型 => 線程池的大小推薦為
CPU數(shù)量 + 1,CPU數(shù)量可以根據(jù)Runtime.availableProcessors方法獲取 - IO密集型 =>
CPU數(shù)量 *CPU利用率 * (1 + 線程等待時間/線程CPU時間) - 混合型 => 將任務分為
CPU密集型和IO密集型,然后分別使用不同的線程池去處理,從而使每個線程池可以根據(jù)各自的工作負載來調(diào)整 - 阻塞隊列 => 推薦使用有界隊列,有界隊列有助于避免資源耗盡的情況發(fā)生
- 拒絕策略 => 默認采用的是
AbortPolicy拒絕策略,直接在程序中拋出RejectedExecutionException異?!疽驗槭沁\行時異常,不強制catch】,這種處理方式不夠優(yōu)雅。處理拒絕策略有以下幾種比較推薦:- 在程序中捕獲
RejectedExecutionException異常,在捕獲異常中對任務進行處理。針對默認拒絕策略 - 使用
CallerRunsPolicy拒絕策略,該策略會將任務交給調(diào)用execute的線程執(zhí)行【一般為主線程】,此時主線程將在一段時間內(nèi)不能提交任何任務,從而使工作線程處理正在執(zhí)行的任務。此時提交的線程將被保存在TCP隊列中,TCP隊列滿將會影響客戶端,這是一種平緩的性能降低 - 自定義拒絕策略,只需要實現(xiàn)
RejectedExecutionHandler接口即可 - 如果任務不是特別重要,使用
DiscardPolicy和DiscardOldestPolicy拒絕策略將任務丟棄也是可以的
- 在程序中捕獲
如果使用Executors的靜態(tài)方法創(chuàng)建 ThreadPoolExecutor 對象,可以通過使用 Semaphore 對任務的執(zhí)行進行限流也可以避免出現(xiàn) OOM 異常
由于線程池參數(shù)定義經(jīng)驗較少,都是理論知識,歡迎有經(jīng)驗的大佬補充
到此這篇關于淺談為什么阿里巴巴要禁用Executors創(chuàng)建線程池的文章就介紹到這了,更多相關阿里巴巴禁用Executors創(chuàng)建線程池內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
spring boot 2.x html中引用css和js失效問題及解決方法
這篇文章主要介紹了spring boot 2.x html中引用css和js失效,需要的朋友可以參考下2018-11-11

