【轉載】硬核乾貨:4W字從源碼上分析JUC線程池ThreadPoolExecutor的實現原理

【轉載】硬核乾貨:4W字從源碼上分析JUC線程池ThreadPoolExecutor的實現原理

前提

很早之前就打算看一次JUC線程池ThreadPoolExecutor的源碼實現,由於近段時間比較忙,一直沒有時間整理出源碼分析的文章。之前在分析擴展線程池實現可回調的Future時候曾經提到併發大師Doug Lea在設計線程池ThreadPoolExecutor的提交任務的頂層接口Executor只有一個無狀態的執行方法:

public interface Executor {

void execute(Runnable command);
}

ExecutorService提供了很多擴展方法底層基本上是基於Executor#execute()方法進行擴展。本文着重分析ThreadPoolExecutor#execute()的實現,筆者會從實現原理、源碼實現等角度結合簡化例子進行詳細的分析。ThreadPoolExecutor的源碼從JDK8JDK11基本沒有變化,本文編寫的時候使用的是JDK11

ThreadPoolExecutor的原理

ThreadPoolExecutor裏面使用到JUC同步器框架AbstractQueuedSynchronizer(俗稱AQS)、大量的位操作、CAS操作。ThreadPoolExecutor提供了固定活躍線程(核心線程)、額外的線程(線程池容量 - 核心線程數這部分額外創建的線程,下面稱爲非核心線程)、任務隊列以及拒絕策略這幾個重要的功能。

JUC同步器框架

ThreadPoolExecutor裏面使用到JUC同步器框架,主要用於四個方面:

  • 全局鎖mainLock成員屬性,是可重入鎖ReentrantLock類型,主要是用於訪問工作線程Worker集合和進行數據統計記錄時候的加鎖操作。
  • 條件變量terminationCondition類型,主要用於線程進行等待終結awaitTermination()方法時的帶期限阻塞。
  • 任務隊列workQueueBlockingQueue<Runnable>類型,任務隊列,用於存放待執行的任務。
  • 工作線程,內部類Worker類型,是線程池中真正的工作線程對象。

關於AQS筆者之前寫過一篇相關源碼分析的文章:JUC同步器框架AbstractQueuedSynchronizer源碼圖文分析

核心線程

這裏先參考ThreadPoolExecutor的實現並且進行簡化,實現一個只有核心線程的線程池,要求如下:

  • 暫時不考慮任務執行異常情況下的處理。
  • 任務隊列爲無界隊列。
  • 線程池容量固定爲核心線程數量。
  • 暫時不考慮拒絕策略。
public class CoreThreadPool implements Executor {

private BlockingQueue<Runnable> workQueue;
private static final AtomicInteger COUNTER = new AtomicInteger();
private int coreSize;
private int threadCount = 0;

public CoreThreadPool(int coreSize) {
this.coreSize = coreSize;
this.workQueue = new LinkedBlockingQueue<>();
}

@Override
public void execute(Runnable command) {
if (++threadCount <= coreSize) {
new Worker(command).start();
} else {
try {
workQueue.put(command);
} catch (InterruptedException e) {
throw new IllegalStateException(e);
}
}
}

private class Worker extends Thread {
private Runnable firstTask;

public Worker(Runnable runnable) {
super(String.format("Worker-%d", COUNTER.getAndIncrement()));
this.firstTask = runnable;
}

@Override
public void run() {
Runnable task = this.firstTask;
while (null != task || null != (task = getTask())) {
try {
task.run();
} finally {
task = null;
}
}
}
}

private Runnable getTask() {
try {
return workQueue.take();
} catch (InterruptedException e) {
throw new IllegalStateException(e);
}
}

public static void main(String[] args) throws Exception {
CoreThreadPool pool = new CoreThreadPool(5);
IntStream.range(0, 10)
.forEach(i -> pool.execute(() ->
System.out.println(String.format("Thread:%s,value:%d", Thread.currentThread().getName(), i))));
Thread.sleep(Integer.MAX_VALUE);
}
}

某次運行結果如下:

Thread:Worker-0,value:0
Thread:Worker-3,value:3
Thread:Worker-2,value:2
Thread:Worker-1,value:1
Thread:Worker-4,value:4
Thread:Worker-1,value:5
Thread:Worker-2,value:8
Thread:Worker-4,value:7
Thread:Worker-0,value:6
Thread:Worker-3,value:9

設計此線程池的時候,核心線程是懶創建的,如果線程空閒的時候則阻塞在任務隊列的take()方法,其實對於ThreadPoolExecutor也是類似這樣實現,只是如果使用了keepAliveTime並且允許核心線程超時(allowCoreThreadTimeOut設置爲true)則會使用BlockingQueue#poll(keepAliveTime)進行輪詢代替永久阻塞。

其他附加功能

構建ThreadPoolExecutor實例的時候,需要定義maximumPoolSize(線程池最大線程數)和corePoolSize(核心線程數)。當任務隊列是有界的阻塞隊列,核心線程滿負載,任務隊列已經滿的情況下,會嘗試創建額外的maximumPoolSize - corePoolSize個線程去執行新提交的任務。當ThreadPoolExecutor這裏實現的兩個主要附加功能是:

  • 一定條件下會創建非核心線程去執行任務,非核心線程的回收週期(線程生命週期終結時刻)是keepAliveTime,線程生命週期終結的條件是:下一次通過任務隊列獲取任務的時候並且存活時間超過keepAliveTime
  • 提供拒絕策略,也就是在覈心線程滿負載、任務隊列已滿、非核心線程滿負載的條件下會觸發拒絕策略。

源碼分析

先分析線程池的關鍵屬性,接着分析其狀態控制,最後重點分析ThreadPoolExecutor#execute()方法。

關鍵屬性

public class ThreadPoolExecutor extends AbstractExecutorService {

// 控制變量-存放狀態和線程數
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

// 任務隊列,必須是阻塞隊列
private final BlockingQueue<Runnable> workQueue;

// 工作線程集合,存放線程池中所有的(活躍的)工作線程,只有在持有全局鎖mainLock的前提下才能訪問此集合
private final HashSet<Worker> workers = new HashSet<>();

// 全局鎖
private final ReentrantLock mainLock = new ReentrantLock();

// awaitTermination方法使用的等待條件變量
private final Condition termination = mainLock.newCondition();

// 記錄峯值線程數
private int largestPoolSize;

// 記錄已經成功執行完畢的任務數
private long completedTaskCount;

// 線程工廠,用於創建新的線程實例
private volatile ThreadFactory threadFactory;

// 拒絕執行處理器,對應不同的拒絕策略
private volatile RejectedExecutionHandler handler;

// 空閒線程等待任務的時間週期,單位是納秒
private volatile long keepAliveTime;

// 是否允許核心線程超時,如果爲true則keepAliveTime對核心線程也生效
private volatile boolean allowCoreThreadTimeOut;

// 核心線程數
private volatile int corePoolSize;

// 線程池容量
private volatile int maximumPoolSize;

// 省略其他代碼
}

下面看參數列表最長的構造函數:

public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}

可以自定義核心線程數、線程池容量(最大線程數)、空閒線程等待任務週期、任務隊列、線程工廠、拒絕策略。下面簡單分析一下每個參數的含義和作用:

  • **corePoolSize**:int類型,核心線程數量。
  • **maximumPoolSize**:int類型,最大線程數量,也就是線程池的容量。
  • **keepAliveTime**:long類型,線程空閒等待時間,也和工作線程的生命週期有關,下文會分析。
  • **unit**:TimeUnit類型,keepAliveTime參數的時間單位,實際上keepAliveTime最終會轉化爲納秒。
  • **workQueue**:BlockingQueue<Runnable>類型,等待隊列或者叫任務隊列。
  • **threadFactory**:ThreadFactory類型,線程工廠,用於創建工作線程(包括核心線程和非核心線程),默認使用Executors.defaultThreadFactory()作爲內建線程工廠實例,一般自定義線程工廠才能更好地跟蹤工作線程。
  • **handler**:RejectedExecutionHandler類型,線程池的拒絕執行處理器,更多時候稱爲拒絕策略,拒絕策略執行的時機是當阻塞隊列已滿、沒有空閒的線程(包括核心線程和非核心線程)並且繼續提交任務。提供了4種內建的拒絕策略實現:
    • AbortPolicy:直接拒絕策略,也就是不會執行任務,直接拋出RejectedExecutionException,這是默認的拒絕策略
    • DiscardPolicy:拋棄策略,也就是直接忽略提交的任務(通俗來說就是空實現)。
    • DiscardOldestPolicy:拋棄最老任務策略,也就是通過poll()方法取出任務隊列隊頭的任務拋棄,然後執行當前提交的任務。
    • CallerRunsPolicy:調用者執行策略,也就是當前調用Executor#execute()的線程直接調用任務Runnable#run()一般不希望任務丟失會選用這種策略,但從實際角度來看,原來的異步調用意圖會退化爲同步調用

狀態控制

狀態控制主要圍繞原子整型成員變量ctl

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int COUNT_MASK = (1 << COUNT_BITS) - 1;

private static final int RUNNING = -1 << COUNT_BITS;
private static final int SHUTDOWN = 0 << COUNT_BITS;
private static final int STOP = 1 << COUNT_BITS;
private static final int TIDYING = 2 << COUNT_BITS;
private static final int TERMINATED = 3 << COUNT_BITS;

// 通過ctl值獲取運行狀態
private static int runStateOf(int c) { return c & ~COUNT_MASK; }
// 通過ctl值獲取工作線程數
private static int workerCountOf(int c) { return c & COUNT_MASK; }

// 通過運行狀態和工作線程數計算ctl的值,或運算
private static int ctlOf(int rs, int wc) { return rs | wc; }

private static boolean runStateLessThan(int c, int s) {
return c < s;
}

private static boolean runStateAtLeast(int c, int s) {
return c >= s;
}

private static boolean isRunning(int c) {
return c < SHUTDOWN;
}

// CAS操作線程數增加1
private boolean compareAndIncrementWorkerCount(int expect) {
return ctl.compareAndSet(expect, expect + 1);
}

// CAS操作線程數減少1
private boolean compareAndDecrementWorkerCount(int expect) {
return ctl.compareAndSet(expect, expect - 1);
}

// 線程數直接減少1
private void decrementWorkerCount() {
ctl.addAndGet(-1);
}

接下來分析一下線程池的狀態變量,工作線程上限數量位的長度是COUNT_BITS,它的值是Integer.SIZE - 3,也就是正整數29:

我們知道,整型包裝類型Integer實例的大小是4 byte,一共32 bit,也就是一共有32個位用於存放0或者1。
在ThreadPoolExecutor實現中,使用32位的整型包裝類型存放工作線程數和線程池狀態。
其中,低29位用於存放工作線程數,而高3位用於存放線程池狀態,所以線程池的狀態最多隻能有2^3種。
工作線程上限數量爲2^29 - 1,超過5億,這個數量在短時間內不用考慮會超限。

接着看工作線程上限數量掩碼COUNT_MASK,它的值是(1 < COUNT_BITS) - l,也就是1左移29位,再減去1,如果補全32位,它的位視圖如下:

j-u-c-t-p-e-1

然後就是線程池的狀態常量,這裏只詳細分析其中一個,其他類同,這裏看RUNNING狀態:

// -1的補碼爲:111-11111111111111111111111111111
// 左移29位後:111-00000000000000000000000000000
// 10進制值爲:-536870912
// 高3位111的值就是表示線程池正在處於運行狀態
private static final int RUNNING = -1 << COUNT_BITS;

控制變量ctl的組成就是通過線程池運行狀態rs和工作線程數wc通過或運算得到的:

// rs=RUNNING值爲:111-00000000000000000000000000000
// wc的值爲0:000-00000000000000000000000000000
// rs | wc的結果爲:111-00000000000000000000000000000
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static int ctlOf(int rs, int wc) {
return rs | wc;
}

那麼我們怎麼從ctl中取出高3位?上面源碼中提供的runStateOf()方法就是提取運行狀態:

// 先把COUNT_MASK取反(~COUNT_MASK),得到:111-00000000000000000000000000000
// ctl位圖特點是:xxx-yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
// 兩者做一次與運算即可得到高3位xxx
private static int runStateOf(int c){
return c & ~COUNT_MASK;
}

同理,取出低29位只需要把ctlCOUNT_MASK(000-11111111111111111111111111111)做一次與運算即可。

小結一下線程池的運行狀態常量:

狀態名稱 位圖 十進制值 描述
RUNNING 111-00000000000000000000000000000 -536870912 運行中狀態,可以接收新的任務和執行任務隊列中的任務
SHUTDOWN 000-00000000000000000000000000000 0 shutdown狀態,不再接收新的任務,但是會執行任務隊列中的任務
STOP 001-00000000000000000000000000000 536870912 停止狀態,不再接收新的任務,也不會執行任務隊列中的任務,中斷所有執行中的任務
TIDYING 010-00000000000000000000000000000 1073741824 整理中狀態,所有任務已經終結,工作線程數爲0,過渡到此狀態的工作線程會調用鉤子方法terminated()
TERMINATED 011-00000000000000000000000000000 1610612736 終結狀態,鉤子方法terminated()執行完畢

這裏有一個比較特殊的技巧,由於運行狀態值存放在高3位,所以可以直接通過十進制值(甚至可以忽略低29位,直接用ctl進行比較,或者使用ctl和線程池狀態常量進行比較)來比較和判斷線程池的狀態:

RUNNING(-536870912) < SHUTDOWN(0) < STOP(536870912) < TIDYING(1073741824) < TERMINATED(1610612736)

下面這三個方法就是使用這種技巧:

// ctl和狀態常量比較,判斷是否小於
private static boolean runStateLessThan(int c, int s) {
return c < s;
}

// ctl和狀態常量比較,判斷是否小於或等於
private static boolean runStateAtLeast(int c, int s) {
return c >= s;
}

// ctl和狀態常量SHUTDOWN比較,判斷是否處於RUNNING狀態
private static boolean isRunning(int c) {
return c < SHUTDOWN;
}

最後是線程池狀態的躍遷圖:

j-u-c-t-p-e-2

PS:線程池源碼中有很多中間變量用了簡單的單字母表示,例如c就是表示ctl、wc就是表示worker count、rs就是表示running status。

execute方法源碼分析

線程池異步執行任務的方法實現是ThreadPoolExecutor#execute(),源碼如下:

// 執行命令,其中命令(下面稱任務)對象是Runnable的實例
public void execute(Runnable command) {
// 判斷命令(任務)對象非空
if (command == null)
throw new NullPointerException();
// 獲取ctl的值
int c = ctl.get();
// 判斷如果當前工作線程數小於核心線程數,則創建新的核心線程並且執行傳入的任務
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
// 如果創建新的核心線程成功則直接返回
return;
// 這裏說明創建核心線程失敗,需要更新ctl的臨時變量c
c = ctl.get();
}
// 走到這裏說明創建新的核心線程失敗,也就是當前工作線程數大於等於corePoolSize
// 判斷線程池是否處於運行中狀態,同時嘗試用非阻塞方法向任務隊列放入任務(放入任務失敗返回false)
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
// 這裏是向任務隊列投放任務成功,對線程池的運行中狀態做二次檢查
// 如果線程池二次檢查狀態是非運行中狀態,則從任務隊列移除當前的任務調用拒絕策略處理之(也就是移除前面成功入隊的任務實例)
if (! isRunning(recheck) && remove(command))
// 調用拒絕策略處理任務 - 返回
reject(command);
// 走到下面的else if分支,說明有以下的前提:
// 0、待執行的任務已經成功加入任務隊列
// 1、線程池可能是RUNNING狀態
// 2、傳入的任務可能從任務隊列中移除失敗(移除失敗的唯一可能就是任務已經被執行了)
// 如果當前工作線程數量爲0,則創建一個非核心線程並且傳入的任務對象爲null - 返回
// 也就是創建的非核心線程不會馬上運行,而是等待獲取任務隊列的任務去執行
// 如果前工作線程數量不爲0,原來應該是最後的else分支,但是可以什麼也不做,因爲任務已經成功入隊列,總會有合適的時機分配其他空閒線程去執行它
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
// 走到這裏說明有以下的前提:
// 0、線程池中的工作線程總數已經大於等於corePoolSize(簡單來說就是核心線程已經全部懶創建完畢)
// 1、線程池可能不是RUNNING狀態
// 2、線程池可能是RUNNING狀態同時任務隊列已經滿了
// 如果向任務隊列投放任務失敗,則會嘗試創建非核心線程傳入任務執行
// 創建非核心線程失敗,此時需要拒絕執行任務
else if (!addWorker(command, false))
// 調用拒絕策略處理任務 - 返回
reject(command);
}

這裏簡單分析一下整個流程:

  1. 如果當前工作線程總數小於corePoolSize,則直接創建核心線程執行任務(任務實例會傳入直接用於構造工作線程實例)。
  2. 如果當前工作線程總數大於等於corePoolSize,判斷線程池是否處於運行中狀態,同時嘗試用非阻塞方法向任務隊列放入任務,這裏會二次檢查線程池運行狀態,如果當前工作線程數量爲0,則創建一個非核心線程並且傳入的任務對象爲null。
  3. 如果向任務隊列投放任務失敗(任務隊列已經滿了),則會嘗試創建非核心線程傳入任務實例執行。
  4. 如果創建非核心線程失敗,此時需要拒絕執行任務,調用拒絕策略處理任務。

這裏是一個疑惑點:爲什麼需要二次檢查線程池的運行狀態,當前工作線程數量爲0,嘗試創建一個非核心線程並且傳入的任務對象爲null?這個可以看API註釋:

如果一個任務成功加入任務隊列,我們依然需要二次檢查是否需要添加一個工作線程(因爲所有存活的工作線程有可能在最後一次檢查之後已經終結)或者執行當前方法的時候線程池是否已經shutdown了。所以我們需要二次檢查線程池的狀態,必須時把任務從任務隊列中移除或者在沒有可用的工作線程的前提下新建一個工作線程。

任務提交流程從調用者的角度來看如下:

j-u-c-t-p-e-3

addWorker方法源碼分析

boolean addWorker(Runnable firstTask, boolean core)方法的第一的參數可以用於直接傳入任務實例,第二個參數用於標識將要創建的工作線程是否核心線程。方法源碼如下:

// 添加工作線程,如果返回false說明沒有新創建工作線程,如果返回true說明創建和啓動工作線程成功
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
// 注意這是一個死循環 - 最外層循環
for (int c = ctl.get();;) {
// 這個是十分複雜的條件,這裏先拆分多個與(&&)條件:
// 1. 線程池狀態至少爲SHUTDOWN狀態,也就是rs >= SHUTDOWN(0)
// 2. 線程池狀態至少爲STOP狀態,也就是rs >= STOP(1),或者傳入的任務實例firstTask不爲null,或者任務隊列爲空
// 其實這個判斷的邊界是線程池狀態爲shutdown狀態下,不會再接受新的任務,在此前提下如果狀態已經到了STOP、或者傳入任務不爲空、或者任務隊列爲空(已經沒有積壓任務)都不需要添加新的線程
if (runStateAtLeast(c, SHUTDOWN)
&& (runStateAtLeast(c, STOP)
|| firstTask != null
|| workQueue.isEmpty()))
return false;
// 注意這也是一個死循環 - 二層循環
for (;;) {
// 這裏每一輪循環都會重新獲取工作線程數wc
// 1. 如果傳入的core爲true,表示將要創建核心線程,通過wc和corePoolSize判斷,如果wc >= corePoolSize,則返回false表示創建核心線程失敗
// 1. 如果傳入的core爲false,表示將要創非建核心線程,通過wc和maximumPoolSize判斷,如果wc >= maximumPoolSize,則返回false表示創建非核心線程失敗
if (workerCountOf(c)
>= ((core ? corePoolSize : maximumPoolSize) & COUNT_MASK))
return false;
// 成功通過CAS更新工作線程數wc,則break到最外層的循環
if (compareAndIncrementWorkerCount(c))
break retry;
// 走到這裏說明了通過CAS更新工作線程數wc失敗,這個時候需要重新判斷線程池的狀態是否由RUNNING已經變爲SHUTDOWN
c = ctl.get(); // Re-read ctl
// 如果線程池狀態已經由RUNNING已經變爲SHUTDOWN,則重新跳出到外層循環繼續執行
if (runStateAtLeast(c, SHUTDOWN))
continue retry;
// 如果線程池狀態依然是RUNNING,CAS更新工作線程數wc失敗說明有可能是併發更新導致的失敗,則在內層循環重試即可
// else CAS failed due to workerCount change; retry inner loop
}
}
// 標記工作線程是否啓動成功
boolean workerStarted = false;
// 標記工作線程是否創建成功
boolean workerAdded = false;
Worker w = null;
try {
// 傳入任務實例firstTask創建Worker實例,Worker構造裏面會通過線程工廠創建新的Thread對象,所以下面可以直接操作Thread t = w.thread
// 這一步Worker實例已經創建,但是沒有加入工作線程集合或者啓動它持有的線程Thread實例
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
// 這裏需要全局加鎖,因爲會改變一些指標值和非線程安全的集合
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
int c = ctl.get();
// 這裏主要在加鎖的前提下判斷ThreadFactory創建的線程是否存活或者判斷獲取鎖成功之後線程池狀態是否已經更變爲SHUTDOWN
// 1. 如果線程池狀態依然爲RUNNING,則只需要判斷線程實例是否存活,需要添加到工作線程集合和啓動新的Worker
// 2. 如果線程池狀態小於STOP,也就是RUNNING或者SHUTDOWN狀態下,同時傳入的任務實例firstTask爲null,則需要添加到工作線程集合和啓動新的Worker
// 對於2,換言之,如果線程池處於SHUTDOWN狀態下,同時傳入的任務實例firstTask不爲null,則不會添加到工作線程集合和啓動新的Worker
// 這一步其實有可能創建了新的Worker實例但是並不啓動(臨時對象,沒有任何強引用),這種Worker有可能成功下一輪GC被收集的垃圾對象
if (isRunning(c) ||
(runStateLessThan(c, STOP) && firstTask == null)) {
if (t.isAlive()) // precheck that t is startable
throw new IllegalThreadStateException();
// 把創建的工作線程實例添加到工作線程集合
workers.add(w);
int s = workers.size();
// 嘗試更新歷史峯值工作線程數,也就是線程池峯值容量
if (s > largestPoolSize)
largestPoolSize = s;
// 這裏更新工作線程是否啓動成功標識爲true,後面纔會調用Thread#start()方法啓動真實的線程實例
workerAdded = true;
}
} finally {
mainLock.unlock();
}
// 如果成功添加工作線程,則調用Worker內部的線程實例t的Thread#start()方法啓動真實的線程實例
if (workerAdded) {
t.start();
// 標記線程啓動成功
workerStarted = true;
}
}
} finally {
// 線程啓動失敗,需要從工作線程集合移除對應的Worker
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}

// 添加Worker失敗
private void addWorkerFailed(Worker w) {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 從工作線程集合移除之
if (w != null)
workers.remove(w);
// wc數量減1
decrementWorkerCount();
// 基於狀態判斷嘗試終結線程池
tryTerminate();
} finally {
mainLock.unlock();
}
}

筆者發現了Doug Lea大神十分喜歡複雜的條件判斷,而且單行復雜判斷不喜歡加花括號,像下面這種代碼在他編寫的很多類庫中都比較常見:

if (runStateAtLeast(c, SHUTDOWN)
&& (runStateAtLeast(c, STOP)
|| firstTask != null
|| workQueue.isEmpty()))
return false;
// ....
// 代碼拆分一下如下
boolean atLeastShutdown = runStateAtLeast(c, SHUTDOWN); # rs >= SHUTDOWN(0)
boolean atLeastStop = runStateAtLeast(c, STOP) || firstTask != null || workQueue.isEmpty();
if (atLeastShutdown && atLeastStop){
return false;
}

上面的分析邏輯中需要注意一點,Worker實例創建的同時,在其構造函數中會通過ThreadFactory創建一個Java線程Thread實例,後面會加鎖後二次檢查是否需要把Worker實例添加到工作線程集合workers中和是否需要啓動Worker中持有的Thread實例,只有啓動了Thread實例實例,Worker才真正開始運作,否則只是一個無用的臨時對象。Worker本身也實現了Runnable接口,它可以看成是一個Runnable的適配器。

工作線程內部類Worker源碼分析

線程池中的每一個具體的工作線程被包裝爲內部類Worker實例,Worker繼承於AbstractQueuedSynchronizer(AQS),實現了Runnable接口:

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{
/**
* This class will never be serialized, but we provide a
* serialVersionUID to suppress a javac warning.
*/
private static final long serialVersionUID = 6138294804551838833L;

// 保存ThreadFactory創建的線程實例,如果ThreadFactory創建線程失敗則爲null
final Thread thread;
// 保存傳入的Runnable任務實例
Runnable firstTask;
// 記錄每個線程完成的任務總數
volatile long completedTasks;

// 唯一的構造函數,傳入任務實例firstTask,注意可以爲null
Worker(Runnable firstTask) {
// 禁止線程中斷,直到runWorker()方法執行
setState(-1); // inhibit interrupts until runWorker
this.firstTask = firstTask;
// 通過ThreadFactory創建線程實例,注意一下Worker實例自身作爲Runnable用於創建新的線程實例
this.thread = getThreadFactory().newThread(this);
}

// 委託到外部的runWorker()方法,注意runWorker()方法是線程池的方法,而不是Worker的方法
public void run() {
runWorker(this);
}

// Lock methods
//
// The value 0 represents the unlocked state.
// The value 1 represents the locked state.
// 是否持有獨佔鎖,state值爲1的時候表示持有鎖,state值爲0的時候表示已經釋放鎖
protected boolean isHeldExclusively() {
return getState() != 0;
}

// 獨佔模式下嘗試獲取資源,這裏沒有判斷傳入的變量,直接CAS判斷0更新爲1是否成功,成功則設置獨佔線程爲當前線程
protected boolean tryAcquire(int unused) {
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}

// 獨佔模式下嘗試是否資源,這裏沒有判斷傳入的變量,直接把state設置爲0
protected boolean tryRelease(int unused) {
setExclusiveOwnerThread(null);
setState(0);
return true;
}

// 加鎖
public void lock() { acquire(1); }

// 嘗試加鎖
public boolean tryLock() { return tryAcquire(1); }

// 解鎖
public void unlock() { release(1); }

// 是否鎖定
public boolean isLocked() { return isHeldExclusively(); }

// 啓動後進行線程中斷,注意這裏會判斷線程實例的中斷標誌位是否爲false,只有中斷標誌位爲false纔會中斷
void interruptIfStarted() {
Thread t;
if (getState() >= 0 && (t = thread) != null && !t.isInterrupted()) {
try {
t.interrupt();
} catch (SecurityException ignore) {
}
}
}
}

Worker的構造函數裏面的邏輯十分重要,通過ThreadFactory創建的Thread實例同時傳入Worker實例,因爲Worker本身實現了Runnable,所以可以作爲任務提交到線程中執行。只要Worker持有的線程實例w調用Thread#start()方法就能在合適時機執行Worker#run()。簡化一下邏輯如下:

// addWorker()方法中構造
Worker worker = createWorker();
// 通過線程池構造時候傳入
ThreadFactory threadFactory = getThreadFactory();
// Worker構造函數中
Thread thread = threadFactory.newThread(worker);
// addWorker()方法中啓動
thread.start();

Worker繼承自AQS,這裏使用了AQS的獨佔模式,這裏有個技巧是構造Worker的時候,把AQS的資源(狀態)通過setState(-1)設置爲-1,這是因爲Worker實例剛創建時AQSstate的默認值爲0,此時線程尚未啓動,不能在這個時候進行線程中斷,見Worker#interruptIfStarted()方法。Worker中兩個覆蓋AQS的方法tryAcquire()tryRelease()都沒有判斷外部傳入的變量,前者直接CAS(0,1),後者直接setState(0)。接着看核心方法ThreadPoolExecutor#runWorker()

final void runWorker(Worker w) {
// 獲取當前線程,實際上和Worker持有的線程實例是相同的
Thread wt = Thread.currentThread();
// 獲取Worker中持有的初始化時傳入的任務對象,這裏注意存放在臨時變量task中
Runnable task = w.firstTask;
// 設置Worker中持有的初始化時傳入的任務對象爲null
w.firstTask = null;
// 由於Worker初始化時AQS中state設置爲-1,這裏要先做一次解鎖把state更新爲0,允許線程中斷
w.unlock(); // allow interrupts
// 記錄線程是否因爲用戶異常終結,默認是true
boolean completedAbruptly = true;
try {
// 初始化任務對象不爲null,或者從任務隊列獲取任務不爲空(從任務隊列獲取到的任務會更新到臨時變量task中)
// getTask()由於使用了阻塞隊列,這個while循環如果命中後半段會處於阻塞或者超時阻塞狀態,getTask()返回爲null會導致線程跳出死循環使線程終結
while (task != null || (task = getTask()) != null) {
// Worker加鎖,本質是AQS獲取資源並且嘗試CAS更新state由0更變爲1
w.lock();
// If pool is stopping, ensure thread is interrupted;
// if not, ensure thread is not interrupted. This
// requires a recheck in second case to deal with
// shutdownNow race while clearing interrupt
// 如果線程池正在停止(也就是由RUNNING或者SHUTDOWN狀態向STOP狀態變更),那麼要確保當前工作線程是中斷狀態
// 否則,要保證當前線程不是中斷狀態
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt();
try {
// 鉤子方法,任務執行前
beforeExecute(wt, task);
try {
task.run();
// 鉤子方法,任務執行後 - 正常情況
afterExecute(task, null);
} catch (Throwable ex) {
// 鉤子方法,任務執行後 - 異常情況
afterExecute(task, ex);
throw ex;
}
} finally {
// 清空task臨時變量,這個很重要,否則while會死循環執行同一個task
task = null;
// 累加Worker完成的任務數
w.completedTasks++;
// Worker解鎖,本質是AQS釋放資源,設置state爲0
w.unlock();
}
}
// 走到這裏說明某一次getTask()返回爲null,線程正常退出
completedAbruptly = false;
} finally {
// 處理線程退出,completedAbruptly爲true說明由於用戶異常導致線程非正常退出
processWorkerExit(w, completedAbruptly);
}
}

這裏重點拆解分析一下判斷當前工作線程中斷狀態的代碼:

if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt();
// 先簡化一下判斷邏輯,如下
// 判斷線程池狀態是否至少爲STOP,rs >= STOP(1)
boolean atLeastStop = runStateAtLeast(ctl.get(), STOP);
// 判斷線程池狀態是否至少爲STOP,同時判斷當前線程的中斷狀態並且清空當前線程的中斷狀態
boolean interruptedAndAtLeastStop = Thread.interrupted() && runStateAtLeast(ctl.get(), STOP);
if (atLeastStop || interruptedAndAtLeastStop && !wt.isInterrupted()){
wt.interrupt();
}

Thread.interrupted()方法獲取線程的中斷狀態同時會清空該中斷狀態,這裏之所以會調用這個方法是因爲在執行上面這個if邏輯同時外部有可能調用shutdownNow()方法,shutdownNow()方法中也存在中斷所有Worker線程的邏輯,但是由於shutdownNow()方法中會遍歷所有Worker做線程中斷,有可能無法及時在任務提交到Worker執行之前進行中斷,所以這個中斷邏輯會在Worker內部執行,就是if代碼塊的邏輯。這裏還要注意的是:STOP狀態下會拒絕所有新提交的任務,不會再執行任務隊列中的任務,同時會中斷所有Worker線程。也就是,即使任務Runnable已經runWorker()中前半段邏輯取出,只要還沒走到調用其Runnable#run(),都有可能被中斷。假設剛好發生了進入if代碼塊的邏輯同時外部調用了shutdownNow()方法,那麼if邏輯內會判斷線程中斷狀態並且重置,那麼shutdownNow()方法中調用的interruptWorkers()就不會因爲中斷狀態判斷出現問題導致二次中斷線程(會導致異常)。

小結一下上面runWorker()方法的核心流程:

  1. Worker先執行一次解鎖操作,用於解除不可中斷狀態。
  2. 通過while循環調用getTask()方法從任務隊列中獲取任務(當然,首輪循環也有可能是外部傳入的firstTask任務實例)。
  3. 如果線程池更變爲STOP狀態,則需要確保工作線程是中斷狀態並且進行中斷處理,否則要保證工作線程必須不是中斷狀態。
  4. 執行任務實例Runnale#run()方法,任務實例執行之前和之後(包括正常執行完畢和異常執行情況)分別會調用鉤子方法beforeExecute()afterExecute()
  5. while循環跳出意味着runWorker()方法結束和工作線程生命週期結束(Worker#run()生命週期完結),會調用processWorkerExit()處理工作線程退出的後續工作。

j-u-c-t-p-e-4

接下來分析一下從任務隊列中獲取任務的getTask()方法和處理線程退出的後續工作的方法processWorkerExit()

getTask方法源碼分析

getTask()方法是工作線程在while死循環中獲取任務隊列中的任務對象的方法:

private Runnable getTask() {
// 記錄上一次從隊列中拉取的時候是否超時
boolean timedOut = false; // Did the last poll() time out?
// 注意這是死循環
for (;;) {
int c = ctl.get();

// Check if queue empty only if necessary.
// 第一個if:如果線程池狀態至少爲SHUTDOWN,也就是rs >= SHUTDOWN(0),則需要判斷兩種情況(或邏輯):
// 1. 線程池狀態至少爲STOP(1),也就是線程池正在停止,一般是調用了shutdownNow()方法
// 2. 任務隊列爲空
// 如果在線程池至少爲SHUTDOWN狀態並且滿足上面兩個條件之一,則工作線程數wc減去1,然後直接返回null
if (runStateAtLeast(c, SHUTDOWN)
&& (runStateAtLeast(c, STOP) || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
// 跑到這裏說明線程池還處於RUNNING狀態,重新獲取一次工作線程數
int wc = workerCountOf(c);

// Are workers subject to culling?
// timed臨時變量勇於線程超時控制,決定是否需要通過poll()此帶超時的非阻塞方法進行任務隊列的任務拉取
// 1.allowCoreThreadTimeOut默認值爲false,如果設置爲true,則允許核心線程也能通過poll()方法從任務隊列中拉取任務
// 2.工作線程數大於核心線程數的時候,說明線程池中創建了額外的非核心線程,這些非核心線程一定是通過poll()方法從任務隊列中拉取任務
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
// 第二個if:
// 1.wc > maximumPoolSize說明當前的工作線程總數大於maximumPoolSize,說明了通過setMaximumPoolSize()方法減少了線程池容量
// 或者 2.timed && timedOut說明了線程命中了超時控制並且上一輪循環通過poll()方法從任務隊列中拉取任務爲null
// 並且 3. 工作線程總數大於1或者任務隊列爲空,則通過CAS把線程數減去1,同時返回null,
// CAS把線程數減去1失敗會進入下一輪循環做重試
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}

try {
// 如果timed爲true,通過poll()方法做超時拉取,keepAliveTime時間內沒有等待到有效的任務,則返回null
// 如果timed爲false,通過take()做阻塞拉取,會阻塞到有下一個有效的任務時候再返回(一般不會是null)
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
// 這裏很重要,只有非null時候才返回,null的情況下會進入下一輪循環
if (r != null)
return r;
// 跑到這裏說明上一次從任務隊列中獲取到的任務爲null,一般是workQueue.poll()方法超時返回null
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}

這個方法中,有兩處十分龐大的if邏輯,對於第一處if可能導致工作線程數減去1直接返回null的場景有:

  1. 線程池狀態爲SHUTDOWN,一般是調用了shutdown()方法,並且任務隊列爲空。
  2. 線程池狀態爲STOP

對於第二處if,邏輯有點複雜,先拆解一下:

// 工作線程總數大於maximumPoolSize,說明了通過setMaximumPoolSize()方法減少了線程池容量
boolean b1 = wc > maximumPoolSize;
// 允許線程超時同時上一輪通過poll()方法從任務隊列中拉取任務爲null
boolean b2 = timed && timedOut;
// 工作線程總數大於1
boolean b3 = wc > 1;
// 任務隊列爲空
boolean b4 = workQueue.isEmpty();
boolean r = (b1 || b2) && (b3 || b4);
if (r) {
if (compareAndDecrementWorkerCount(c)){
return null;
}else{
continue;
}
}

這段邏輯大多數情況下是針對非核心線程。在execute()方法中,當線程池總數已經超過了corePoolSize並且還小於maximumPoolSize時,當任務隊列已經滿了的時候,會通過addWorker(task,false)添加非核心線程。而這裏的邏輯恰好類似於addWorker(task,false)的反向操作,用於減少非核心線程,使得工作線程總數趨向於corePoolSize。如果對於非核心線程,上一輪循環獲取任務對象爲null,這一輪循環很容易滿足timed && timedOut爲true,這個時候getTask()返回null會導致Worker#runWorker()方法跳出死循環,之後執行processWorkerExit()方法處理後續工作,而該非核心線程對應的Worker則變成“遊離對象”,等待被JVM回收。當allowCoreThreadTimeOut設置爲true的時候,這裏分析的非核心線程的生命週期終結邏輯同時會適用於核心線程。那麼可以總結出keepAliveTime的意義:

  • 當允許核心線程超時,也就是allowCoreThreadTimeOut設置爲true的時候,此時keepAliveTime表示空閒的工作線程的存活週期。
  • 默認情況下不允許核心線程超時,此時keepAliveTime表示空閒的非核心線程的存活週期。

在一些特定的場景下,配置合理的keepAliveTime能夠更好地利用線程池的工作線程資源。

processWorkerExit方法源碼分析

processWorkerExit()方法是爲將要終結的Worker做一次清理和數據記錄工作(因爲processWorkerExit()方法也包裹在runWorker()方法finally代碼塊中,其實工作線程在執行完processWorkerExit()方法纔算真正的終結)。

private void processWorkerExit(Worker w, boolean completedAbruptly) {
// 因爲拋出用戶異常導致線程終結,直接使工作線程數減1即可
// 如果沒有任何異常拋出的情況下是通過getTask()返回null引導線程正常跳出runWorker()方法的while死循環從而正常終結,這種情況下,在getTask()中已經把線程數減1
if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted
decrementWorkerCount();

final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 全局的已完成任務記錄數加上此將要終結的Worker中的已完成任務數
completedTaskCount += w.completedTasks;
// 工作線程集合中移除此將要終結的Worker
workers.remove(w);
} finally {
mainLock.unlock();
}

// 見下一小節分析,用於根據當前線程池的狀態判斷是否需要進行線程池terminate處理
tryTerminate();

int c = ctl.get();
// 如果線程池的狀態小於STOP,也就是處於RUNNING或者SHUTDOWN狀態的前提下:
// 1.如果線程不是由於拋出用戶異常終結,如果允許核心線程超時,則保持線程池中至少存在一個工作線程
// 2.如果線程由於拋出用戶異常終結,或者當前工作線程數,那麼直接添加一個新的非核心線程
if (runStateLessThan(c, STOP)) {
if (!completedAbruptly) {
// 如果允許核心線程超時,最小值爲0,否則爲corePoolSize
int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
// 如果最小值爲0,同時任務隊列不空,則更新最小值爲1
if (min == 0 && ! workQueue.isEmpty())
min = 1;
// 工作線程數大於等於最小值,直接返回不新增非核心線程
if (workerCountOf(c) >= min)
return; // replacement not needed
}
addWorker(null, false);
}
}

代碼的後面部分區域,會判斷線程池的狀態,如果線程池是RUNNING或者SHUTDOWN狀態的前提下,如果當前的工作線程由於拋出用戶異常被終結,那麼會新創建一個非核心線程。如果當前的工作線程並不是拋出用戶異常被終結(正常情況下的終結),那麼會這樣處理:

  • allowCoreThreadTimeOut爲true,也就是允許核心線程超時的前提下,如果任務隊列空,則會通過創建一個非核心線程保持線程池中至少有一個工作線程。
  • allowCoreThreadTimeOut爲false,如果工作線程總數大於corePoolSize則直接返回,否則創建一個非核心線程,也就是會趨向於保持線程池中的工作線程數量趨向於corePoolSize

processWorkerExit()執行完畢之後,意味着該工作線程的生命週期已經完結。

tryTerminate方法源碼分析

每個工作線程終結的時候都會調用tryTerminate()方法:

final void tryTerminate() {
for (;;) {
int c = ctl.get();
// 判斷線程池的狀態,如果是下面三種情況下的任意一種則直接返回:
// 1.線程池處於RUNNING狀態
// 2.線程池至少爲TIDYING狀態,也就是TIDYING或者TERMINATED狀態,意味着已經走到了下面的步驟,線程池即將終結
// 3.線程池至少爲STOP狀態並且任務隊列不爲空
if (isRunning(c) ||
runStateAtLeast(c, TIDYING) ||
(runStateLessThan(c, STOP) && ! workQueue.isEmpty()))
return;
// 工作線程數不爲0,則中斷工作線程集合中的第一個空閒的工作線程
if (workerCountOf(c) != 0) { // Eligible to terminate
interruptIdleWorkers(ONLY_ONE);
return;
}

final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// CAS設置線程池狀態爲TIDYING,如果設置成功則執行鉤子方法terminated()
if (ctl.compareAndSet(c, ctlOf(TIDYING, 0))) {
try {
terminated();
} finally {
// 最後更新線程池狀態爲TERMINATED
ctl.set(ctlOf(TERMINATED, 0));
// 喚醒阻塞在termination條件的所有線程,這個變量的await()方法在awaitTermination()中調用
termination.signalAll();
}
return;
}
} finally {
mainLock.unlock();
}
// else retry on failed CAS
}
}

// 中斷空閒的工作線程,onlyOne爲true的時候,只會中斷工作線程集合中的某一個線程
private void interruptIdleWorkers(boolean onlyOne) {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
for (Worker w : workers) {
Thread t = w.thread;
// 這裏判斷線程不是中斷狀態並且嘗試獲取鎖成功的時候才進行線程中斷
if (!t.isInterrupted() && w.tryLock()) {
try {
t.interrupt();
} catch (SecurityException ignore) {
} finally {
w.unlock();
}
}
// 這裏跳出循環,也就是隻中斷集合中第一個工作線程
if (onlyOne)
break;
}
} finally {
mainLock.unlock();
}
}

這裏有疑惑的地方是tryTerminate()方法的第二個if代碼邏輯:工作線程數不爲0,則中斷工作線程集合中的第一個空閒的工作線程。方法API註釋中有這樣一段話:

If otherwise eligible to terminate but workerCount is nonzero, interrupts an idle worker to ensure that shutdown signals propagate.
當滿足終結線程池的條件但是工作線程數不爲0,這個時候需要中斷一個空閒的工作線程去確保線程池關閉的信號得以傳播。

下面將會分析的shutdown()方法中會通過interruptIdleWorkers()中斷所有的空閒線程,這個時候有可能有非空閒的線程在執行某個任務,執行任務完畢之後,如果它剛好是核心線程,就會在下一輪循環阻塞在任務隊列的take()方法,如果不做額外的干預,它甚至會在線程池關閉之後永久阻塞在任務隊列的take()方法中。爲了避免這種情況,每個工作線程退出的時候都會嘗試中斷工作線程集合中的某一個空閒的線程,確保所有空閒的線程都能夠正常退出。

interruptIdleWorkers()方法中會對每一個工作線程先進行tryLock()判斷,只有返回true纔有可能進行線程中斷。我們知道runWorker()方法中,工作線程在每次從任務隊列中獲取到非null的任務之後,會先進行加鎖Worker#lock()操作,這樣就能避免線程在執行任務的過程中被中斷,保證被中斷的一定是空閒的工作線程。

shutdown方法源碼分析

線程池關閉操作有幾個相關的變體方法,先看shutdown()

public void shutdown() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 權限校驗,安全策略相關判斷
checkShutdownAccess();
// 設置SHUTDOWN狀態
advanceRunState(SHUTDOWN);
// 中斷所有的空閒的工作線程
interruptIdleWorkers();
// 鉤子方法
onShutdown(); // hook for ScheduledThreadPoolExecutor
} finally {
mainLock.unlock();
}
// 調用上面分析果敢的嘗試terminate方法,使狀態更變爲TIDYING,執行鉤子方法terminated()後,最終狀態更新爲TERMINATED
tryTerminate();
}

// 升提狀態
private void advanceRunState(int targetState) {
// assert targetState == SHUTDOWN || targetState == STOP;
for (;;) {
int c = ctl.get();
// 線程池狀態至少爲targetState或者CAS設置狀態爲targetState則跳出循環
if (runStateAtLeast(c, targetState) ||
ctl.compareAndSet(c, ctlOf(targetState, workerCountOf(c))))
break;
}
}

// 中斷所有的空閒的工作線程
private void interruptIdleWorkers() {
interruptIdleWorkers(false);
}

接着看shutdownNow()方法:

public List<Runnable> shutdownNow() {
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 權限校驗,安全策略相關判斷
checkShutdownAccess();
// 設置STOP狀態
advanceRunState(STOP);
// 中斷所有的工作線程
interruptWorkers();
// 清空工作隊列並且取出所有的未執行的任務
tasks = drainQueue();
} finally {
mainLock.unlock();
}
// 調用上面分析果敢的嘗試terminate方法,使狀態更變爲TIDYING,執行鉤子方法terminated()後,最終狀態更新爲TERMINATED
tryTerminate();
return tasks;
}

// 遍歷所有的工作線程,如果state > 0(啓動狀態)則進行中斷
private void interruptWorkers() {
// assert mainLock.isHeldByCurrentThread();
for (Worker w : workers)
w.interruptIfStarted();
}

shutdownNow()方法會把線程池狀態先更變爲STOP,中斷所有的工作線程(AbstractQueuedSynchronizerstate值大於0的Worker實例,也就是包括正在執行任務的Worker和空閒的Worker),然後遍歷任務隊列,取出(移除)所有任務存放在一個列表中返回。

最後看awaitTermination()方法:

public boolean awaitTermination(long timeout, TimeUnit unit)
throws InterruptedException {
// 轉換timeout的單位爲納秒
long nanos = unit.toNanos(timeout);
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 循環等待直到線程池狀態更變爲TERMINATED,每輪循環等待nanos納秒
while (runStateLessThan(ctl.get(), TERMINATED)) {
if (nanos <= 0L)
return false;
nanos = termination.awaitNanos(nanos);
}
return true;
} finally {
mainLock.unlock();
}
}

awaitTermination()雖然不是shutdown()方法體系,但是它的處理邏輯就是確保調用此方法的線程會阻塞到tryTerminate()方法成功把線程池狀態更新爲TERMINATED後再返回,可以使用在某些需要感知線程池終結時刻的場景。

有一點值得關注的是:shutdown()方法只會中斷空閒的工作線程,如果工作線程正在執行任務對象Runnable#run(),這種情況下的工作線程不會中斷,而是等待下一輪執行getTask()方法的時候通過線程池狀態判斷正常終結該工作線程。

理解可重入鎖mainLock成員變量

private final ReentrantLock mainLock = new ReentrantLock();
private final Condition termination = mainLock.newCondition();

先看了ThreadPoolExecutor內部成員屬性mainLock的引用情況:

歸結一下mainLock的使用場景:

方法 主要作用
tryTerminate 保證狀態TIDYING -> TERMINATED,鉤子方法terminated()回調和條件變量喚醒
interruptIdleWorkers 保護工作線程中斷的串行化,避免”中斷風暴”
addWorker 保護工作線程集合避免併發增加工作線程、保護度量統計數據變更
processWorkerExit 保護度量統計數據變更
shutdownshutdownNowawaitTermination 見下文分析
getPoolSizegetActiveCountgetLargestPoolSizegetTaskCountgetCompletedTaskCount 保護度量統計數據讀取,這些統計數據來一般源於Worker集合的屬性統計

這裏分析一下線程池如何通過可重入鎖和條件變量實現相對優雅地關閉。先看shutdown()方法:

public void shutdown() {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
checkShutdownAccess();
advanceRunState(SHUTDOWN);
interruptIdleWorkers();
onShutdown(); // hook for ScheduledThreadPoolExecutor
} finally {
mainLock.unlock();
}
tryTerminate();
}

這裏shutdown()中除了tryTerminate(),其他它方法都是包裹在鎖裏面執行,**確保工作線程集合穩定性以及關閉權限、確保狀態變更串行化,中斷所有工作線程並且避免工作線程”中斷風暴”**(多次併發調用shutdown()如果不加鎖,會反覆中斷工作線程)。

public List<Runnable> shutdownNow() {
List<Runnable> tasks;
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
checkShutdownAccess();
advanceRunState(STOP);
interruptWorkers();
tasks = drainQueue(); # <--- 多了這一步
} finally {
mainLock.unlock();
}
tryTerminate();
return tasks;
}

shutdownNow()方法其實加鎖的目的和shutdown()差不多,不過多了一步:導出任務隊列中的剩餘的任務實例列表。awaitTermination()方法中使用到前面提到過的條件變量termination

// 條件變量必須在鎖代碼塊中執行,和synchronized關鍵字用法差不多
public boolean awaitTermination(long timeout, TimeUnit unit)
throws InterruptedException {
long nanos = unit.toNanos(timeout);
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// 死循環確保等待執行和狀態變更爲TERMINATED
while (runStateLessThan(ctl.get(), TERMINATED)) {
if (nanos <= 0L)
return false;
nanos = termination.awaitNanos(nanos); # <-- 確保當前調用線程阻塞等待對應的時間或者線程池狀態變更爲TERMINATED,再退出等待
}
return true;
} finally {
mainLock.unlock();
}
}

awaitTermination()方法的核心功能是:確保當前調用awaitTermination()方法的線程阻塞等待對應的時間或者線程池狀態變更爲TERMINATED,再退出等待返回結果,這樣能夠讓使用者輸入一個可以接受的等待時間進行阻塞等待,或者線程池在其他線程中被調用了shutdown()方法狀態變更爲TERMINATED就能正常解除阻塞。awaitTermination()方法的返回值爲布爾值,true代表線程池狀態變更爲TERMINATED或者等待了輸入時間範圍內的時間週期被喚醒,意味則線程池正常退出,結果爲false代表等待了超過輸入時間範圍內的時間週期,線程池的狀態依然沒有更變爲TERMINATED

線程池中的工作線程如何優雅地退出,不導致當前任務執行丟失、任務狀態異常或者任務持有的數據異常,是一個很值得探討的專題,以後有機會一定會分析一下這個專題。

reject方法源碼分析

reject(Runnable command)方法很簡單:

final void reject(Runnable command) {
handler.rejectedExecution(command, this);
}

調用線程池持有的成員RejectedExecutionHandler實例回調任務實例和當前線程池實例。

鉤子方法分析

JDK11爲止,ThreadPoolExecutor提供的鉤子方法沒有增加,有以下幾個:

  • beforeExecute(Thread t, Runnable r):任務對象Runnable#run()執行之前觸發回調。
  • afterExecute(Runnable r, Throwable t):任務對象Runnable#run()執行之後(包括異常完成情況和正常完成情況)觸發回調。
  • terminated():線程池關閉的時候,狀態更變爲TIDYING成功之後會回調此方法,執行此方法完畢後,線程池狀態會更新爲TERMINATED
  • onShutdown()shutdown()方法執行時候會回調此方法,API註釋中提到此方法主要提供給ScheduledThreadPoolExecutor使用。

其中onShutdown()的方法修飾符爲default,其他三個方法的修飾符爲protected,必要時候可以自行擴展這些方法,可以實現監控、基於特定時機觸發具體操作等等。

其他方法

線程池本身提供了大量數據統計相關的方法、擴容方法、預創建方法等等,這些方法的源碼並不複雜,這裏不做展開分析。

核心線程相關:

  • getCorePoolSize():獲取核心線程數。
  • setCorePoolSize():重新設置線程池的核心線程數。
  • prestartCoreThread():預啓動一個核心線程,當且僅當工作線程數量小於核心線程數量。
  • prestartAllCoreThreads():預啓動所有核心線程。

線程池容量相關:

  • getMaximumPoolSize():獲取線程池容量。
  • setMaximumPoolSize():重新設置線程池的最大容量。

線程存活週期相關:

  • setKeepAliveTime():設置空閒工作線程的存活週期。
  • getKeepAliveTime():獲取空閒工作線程的存活週期。

其他監控統計相關方法:

  • getTaskCount():獲取所有已經被執行的任務總數的近似值。
  • getCompletedTaskCount():獲取所有已經執行完成的任務總數的近似值。
  • getLargestPoolSize():獲取線程池的峯值線程數(最大池容量)。
  • getActiveCount():獲取所有活躍線程總數(正在執行任務的工作線程)的近似值。
  • getPoolSize():獲取工作線程集合的容量(當前線程池中的總工作線程數)。

任務隊列操作相關方法:

  • purge():移除任務隊列中所有是Future類型並且已經處於Cancelled狀態的任務。
  • remove():從任務隊列中移除指定的任務。
  • BlockingQueue<Runnable> getQueue():獲取任務隊列的引用。

有部分屬性值的設置有可能影響到線程池中的狀態或者工作線程的增減等,例如核心線程數改變,有可能會直接增減Worker,這裏就以ThreadPoolExecutor#setCorePoolSize()爲例:

// 設置核心線程數量
public void setCorePoolSize(int corePoolSize) {
// 輸入值不能小於0或者大於線程池的容量
if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
// delta = 傳入核心線程數和現存的核心線程數的差值
int delta = corePoolSize - this.corePoolSize;
this.corePoolSize = corePoolSize;
// 如果當前線程池工作線程的總量大於傳入核心線程數,則中斷所有的工作線程
if (workerCountOf(ctl.get()) > corePoolSize)
interruptIdleWorkers();
else if (delta > 0) {
// 傳入核心線程數和現存的核心線程數的差值大於0,也就是核心線程擴容
// 計算傳入核心線程數和現存的核心線程數的差值和任務隊列中任務個數的最小值,並且添加這個最小值個數的工作線程池
// 任務隊列爲空的情況下,k === 0,此時第一個條件 k--> 0就不滿足,不會進入循環,那麼這delta個需要創建的工作線程應該是在提交新任務的時候懶創建
int k = Math.min(delta, workQueue.size());
while (k-- > 0 && addWorker(null, true)) {
// 如果任務隊列爲空,則跳出循環
if (workQueue.isEmpty())
break;
}
}
}

這裏else if (delta > 0)後面的代碼塊中有一段描述,翻譯一下:我們並不知道真正情況下”需要”多少新的工作線程。作爲一種啓發式處理方式,預先啓動足夠多的新的工作線程(直到數量爲核心線程池大小)來處理隊列中當前的任務,但如果在這樣做時隊列變爲空,則停止創建新的工作線程。

小結

本文花大量功夫基於每一行代碼分析JUC線程池ThreadPoolExecutor的核心方法execute()的實現,這個方法是整個線程池相關體系的基石,有了它才能擴展出帶回調的異步執行和基於時間進行任務調度的功能,後面將會編寫兩篇文章分別詳細分析線程池擴展服務ExecutorService的功能源碼實現以及調度線程池ScheduledThreadPoolExecutor的源碼實現,預計要耗時2-3周。

修訂記錄

序號 時間 提議者 修訂描述
1 2020-03-11 小馬過河Valine評論 修正shutdownNow()方法源碼分析的紕漏
2 2020-08-23 雄哥 指出可重入鎖內部屬性mainLock的作用

轉載地址:

硬核乾貨:4W字從源碼上分析JUC線程池ThreadPoolExecutor的實現原理

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章