13518219792
這篇文章將為大家詳細講解有關禁用Executors創建線程池的原因有哪些，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
線程池的定義
管理一組工作線程。通過線程池復用線程有以下幾點優點：
減少資源創建 => 減少內存開銷，創建線程占用內存
降低系統開銷 => 創建線程需要時間，會延遲處理的請求
提高穩定穩定性 => 避免無限創建線程引起的OutOfMemoryError【簡稱OOM】
根據返回的對象類型創建線程池可以分為三類：
創建返回ThreadPoolExecutor對象
創建返回ScheduleThreadPoolExecutor對象
創建返回ForkJoinPool對象
本文只討論創建返回ThreadPoolExecutor 對象
在介紹Executors 創建線程池方法前先介紹一下ThreadPoolExecutor ，因為這些創建線程池的靜態方法都是返回ThreadPoolExecutor 對象，和我們手動創建ThreadPoolExecutor 對象的區別就是我們不需要自己傳構造函數的參數。ThreadPoolExecutor 的構造函數共有四個，但最終調用的都是同一個：
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueueworkQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)
構造函數參數說明：
corePoolSize => 線程池核心線程數量
maximumPoolSize => 線程池較大數量
keepAliveTime => 空閑線程存活時間
unit => 時間單位
workQueue => 線程池所使用的緩沖隊列
threadFactory => 線程池創建線程使用的工廠
handler => 線程池對拒絕任務的處理策略
執行邏輯說明：
判斷核心線程數是否已滿，核心線程數大小和corePoolSize參數有關，未滿則創建線程執行任務
若核心線程池已滿，判斷隊列是否滿，隊列是否滿和workQueue參數有關，若未滿則加入隊列中
若隊列已滿，判斷線程池是否已滿，線程池是否已滿和maximumPoolSize參數有關，若未滿創建線程執行任務
若線程池已滿，則采用拒絕策略處理無法執執行的任務，拒絕策略和handler參數有關
Executors 創建返回ThreadPoolExecutor對象的方法共有三種：
Executors#newCachedThreadPool => 創建可緩存的線程池
Executors#newSingleThreadExecutor => 創建單線程的線程池
Executors#newFixedThreadPool => 創建固定長度的線程池
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue());
} CachedThreadPool 是一個根據需要創建新線程的線程池
corePoolSize => 0，核心線程池的數量為0
maximumPoolSize => Integer.MAX_VALUE，線程池較大數量為Integer.MAX_VALUE，可以認為可以無限創建線程
keepAliveTime => 60L
unit => 秒
workQueue => SynchronousQueue
當一個任務提交時，corePoolSize 為0不創建核心線程，SynchronousQueue 是一個不存儲元素的隊列，可以理解為隊里永遠是滿的，因此最終會創建非核心線程來執行任務。對于非核心線程空閑60s時將被回收。 因為Integer.MAX_VALUE 非常大，可以認為是可以無限創建線程的，在資源有限的情況下容易引起OOM異常
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue()));
} SingleThreadExecutor 是單線程線程池，只有一個核心線程
corePoolSize => 1，核心線程池的數量為1
maximumPoolSize => 1，線程池較大數量為1，即最多只可以創建一個線程，的線程就是核心線程
keepAliveTime => 0L
unit => 毫秒
workQueue => LinkedBlockingQueue
當一個任務提交時，首先會創建一個核心線程來執行任務，如果超過核心線程的數量，將會放入隊列中， 因為LinkedBlockingQueue 是長度為Integer.MAX_VALUE 的隊列，可以認為是無界隊列，因此往隊列中可以插入無限多的任務，在資源有限的時候容易引起OOM 異常 ，同時因為無界隊列，maximumPoolSize 和keepAliveTime 參數將無效，壓根就不會創建非核心線程
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue());
} FixedThreadPool 是固定核心線程的線程池，固定核心線程數由用戶傳入
corePoolSize => 1，核心線程池的數量為1 maximumPoolSize => 1，只可以創建一個非核心線程 keepAliveTime => 0L unit => 秒 workQueue => LinkedBlockingQueue 它和SingleThreadExecutor 類似，的區別就是核心線程數不同，并且由于 使用的是LinkedBlockingQueue ，在資源有限的時候容易引起OOM 異常
corePoolSize => nThreads，核心線程池的數量為1
maximumPoolSize => nThreads，線程池較大數量為nThreads，即最多只可以創建nThreads個線程
keepAliveTime => 0L
unit => 毫秒
workQueue => LinkedBlockingQueue
它和SingleThreadExecutor類似，的區別就是核心線程數不同，并且由于使用的是LinkedBlockingQueue，在資源有限的時候容易引起OOM異常
這就是為什么禁止使用Executors 去創建線程池，而是推薦自己去創建ThreadPoolExecutor 的原因
理論上會出現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 異常
關于禁用Executors創建線程池的原因有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
