您好,登錄后才能下訂單哦!
本篇內容介紹了“為什么要禁用Executors創建線程池”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
線程池的定義
管理一組工作線程。通過線程池復用線程有以下幾點優點:
減少資源創建 => 減少內存開銷,創建線程占用內存
降低系統開銷 => 創建線程需要時間,會延遲處理的請求
提高穩定穩定性 => 避免無限創建線程引起的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,可以認為最大線程數是無限的
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 => 1,核心線程池的數量為1
maximumPoolSize => 1,只可以創建一個非核心線程
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異常。
“為什么要禁用Executors創建線程池”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。