阿里面試官鬼得很,問我為什麼他們阿里要禁用Executors創建執行緒池?

  • 2019 年 11 月 29 日
  • 筆記

作者:何甜甜在嗎

來源:http://rrd.me/eUh6V

看阿里巴巴開發手冊並發編程這塊有一條:執行緒池不允許使用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,可以認為最大執行緒數是無限的
  • 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異常

由於執行緒池參數定義經驗較少,都是理論知識,歡迎有經驗的大佬補充.