深入剖析ThreadPool的執行原理
執行緒在執行任務時，正常的情況是這樣的：
Thread t=new Thread(new Runnable() {
@Override
public void run() {
// TODO Auto-generated method stub
}
});
t.start();
Thread 在初始化的時候傳入一個Runnable,以後就沒有機會再傳入一個Runable了。那麼，woker作為一個已經啟動的執行緒。是如何不斷獲取Runnable的呢？
這個時候可以使用一個包裝器，將執行緒包裝起來，在Run方法內部獲取任務。
public final class Worker implements Runnable {
Thread thread = null;
Runnable task;
private BlockingQueue<Runnable> queues;
public Worker(Runnable task, BlockingQueue<Runnable> queues) {
this.thread = new Thread(this);
this.task = task;
this.queues = queues;
}
public void run() {
if (task != null) {
task.run();
}
try {
while (true) {
task = queues.take();
if (task != null) {
task.run();
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public void start() {
this.thread.start();
}
}
public class Main {
public static void main(String[] args) {
BlockingQueue<Runnable> queues=new ArrayBlockingQueue<Runnable>(100);
Worker worker=new Worker(new Runnable() {
public void run() {
System.out.println("hello!!! ");
try {
Thread.currentThread().sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}, queues);
worker.start();
for(int i=0;i<100;i++){
queues.offer(new Runnable() {
public void run() {
System.out.println("hello!!! ");
try {
Thread.currentThread().sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
}
}
}
這樣我們就簡單地實現了一個“執行緒池”（可以將這個“執行緒池”改造成官方的模式，不過可以自己嘗試一下）。ThreadPool的這種實現模式是併發程式設計中經典的Cyclic Work Distribution模式。
那麼，這種實現的執行緒池效能如何呢？
由於其任務佇列使用的是阻塞佇列，在佇列內部是自旋的。Reeteenlok是改進的CLH佇列。自旋鎖會耗費一定CPU的資源，在擁有大量任務執行下的情況下比較有效。而且，執行緒池中的執行緒並沒有睡眠，而是進入了自旋狀態。
CPU的執行緒與關係
如果是不支援超執行緒的CPU，在同一時刻的確只能處理2個執行緒，但是並不意味著雙核的CPU只能處理兩個執行緒，它可以通過切換上下文來執行多個執行緒。比如我只有一個大腦，但是我要處理5個人提交的任務，我可以處理完A的事情後，把事情的中間結果儲存下，然後再處理B的，然後再讀取A的中間結果，處理A的事情。
JDK中的執行緒池實現分析
Woker自身繼承了Runnable,並對Thread做了一個包裝。Woker程式碼如下所示：
private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable
{
private static final long serialVersionUID = 6138294804551838833L;
Runnable firstTask;
volatile long completedTasks;
Worker(Runnable firstTask) {
setState(-1); // inhibit interrupts until runWorker
this.firstTask = firstTask;
this.thread = getThreadFactory().newThread(this);
}
public void run() {
runWorker(this);
}
protected boolean isHeldExclusively() {
return getState() != 0;
}
protected boolean tryAcquire(int unused) {
if (compareAndSetState(0, 1)) {
setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
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(); }
void interruptIfStarted() {
Thread t;
if (getState() >= 0 && (t = thread) != null && !t.isInterrupted()) {
try {
t.interrupt();
} catch (SecurityException ignore) {
}
}
}
}
execute(Runnable command)方法內部是這樣的：
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}
ctl一個合併型別的值。將當前執行緒數和執行緒池狀態通過數學運算合併到了一個值。具體是如何合併的可以參看一下原始碼，這裡就不敘述了。繼續向下走：
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
可以看到，如果當前執行緒數量小於了核心執行緒數量corePoolSize，就直接增加執行緒處理任務。與佇列沒有關係。但是緊接著又檢查了一遍狀態，因為在這個過程中，別的執行緒也可能在新增任務。繼續向下走：
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
可以看到如果執行緒池是執行態的，就把執行緒新增到任務佇列。workQueue是建構函式傳遞過來的，可以是有界佇列，也可以是無界佇列。可以看出來，佇列如果是無界的，直接往佇列裡面新增任務，這個時候，執行緒池中的執行緒也不會增加，一直會等於核心執行緒數。
如果佇列是有界的，就嘗試直接新增執行緒處理任務，如果新增任務失敗，就呼叫reject方法來處理新增失敗的任務：
else if (!addWorker(command, false))
reject(command);
來看看addWorker是如何實現的，邏輯流程已經直接在註釋中說明了。
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
//如果狀態大於SHUTDOWN，不再接受新的任務，直接返回
if (rs >= SHUTDOWN &&
! (rs == SHUTDOWN &&
firstTask == null &&
! workQueue.isEmpty()))
return false;
/**根據core來判斷，如果當前執行緒數量大於corePoolSize或者最大執行緒數，直接返回。新增任務失敗。
**如果佇列是有界的或者任務新增到佇列失敗(引數core是false)，那麼就會新開一個執行緒處理業務，但如果執行緒已經大於了maximumPoolSize，就會出現新增失敗，返回false。
*/
for (;;) {
int wc = workerCountOf(c);
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false;
if (compareAndIncrementWorkerCount(c))
break retry;
c = ctl.get(); // Re-read ctl
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
}
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
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 rs = runStateOf(ctl.get());
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && 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;
workerAdded = true;
}
} finally {
mainLock.unlock();
}
if (workerAdded) {
t.start();
workerStarted = true;
}
}
} finally {
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}
如果建立失敗的情況下會呼叫addWorkerFailed方法，從而將減少實際執行緒數。
addWorker中for迴圈的意義
在addWorker中有這麼一段程式碼，表示為當前執行緒數加1：
private boolean compareAndIncrementWorkerCount(int expect) {
return ctl.compareAndSet(expect, expect + 1);
}
由於多執行緒可能同時操作。expect值可能會變化。僅僅一次的操作compareAndIncrementWorkerCount可能一次並不會成功，而且，一個執行緒在執行addWork的過程中間，另外一個執行緒假設直接shotdown這個執行緒池。for迴圈的存在可以保證狀態一定是一致的。
任務的執行
在Worker中間實際上是呼叫的runWorker方法來執行的具體業務：
final void runWorker(Worker w) {
Thread wt = Thread.currentThread();
Runnable task = w.firstTask;
w.firstTask = null;
w.unlock(); // allow interrupts
boolean completedAbruptly = true;
try {
while (task != null || (task = getTask()) != null) {
w.lock();
if ((runStateAtLeast(ctl.get(), STOP) ||
(Thread.interrupted() &&
runStateAtLeast(ctl.get(), STOP))) &&
!wt.isInterrupted())
wt.interrupt();
try {
beforeExecute(wt, task);
Throwable thrown = null;
try {
task.run();
} catch (RuntimeException x) {
thrown = x; throw x;
} catch (Error x) {
thrown = x; throw x;
} catch (Throwable x) {
thrown = x; throw new Error(x);
} finally {
afterExecute(task, thrown);
}
} finally {
task = null;
w.completedTasks++;
w.unlock();
}
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}
可以看到while迴圈不斷的從佇列中取出任務執行。如果task==null 並且getTask()等於null的話，那麼就會跳出迴圈，進入到processWorkerExit，run方法執行完畢以後，這個執行緒也被銷燬了。但是為什麼在各自的執行緒執行，為什麼還需要加鎖呢？答案是因為要執行緒池需要判斷這個執行緒是否在執行任務。在interruptIdleWorkers方法中，要中斷那寫目前空閒的執行緒，通過當前Worker是否獲得了鎖就能判斷這個worker是否是空閒的:
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(); //中斷不起作用。interrupt()對於自旋鎖是不起作用的。只是邏輯上被阻塞，
}
}
if (onlyOne)
break;
}
} finally {
mainLock.unlock();
}
}
可以看到，如果w.tryLock()可以獲取到鎖，那麼就意味著當前的 Woker並沒有處理任務（沒有進入到迴圈裡面或者被getTask方法所阻塞，無法獲取鎖）。
Work之所以繼承AbstractQueuedSynchronizer，而不去使用ReentrantLock。是因為ReentrantLock是可重入鎖，在呼叫lock方法獲取鎖之後，再呼叫tryLock()還是會返回true。
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock();
lock.lock();
System.out.println(lock.tryLock());
}
輸出結果是true，所以使用ReentrantLock則難以判斷當前Worker是否在執行任務。
執行緒超時allowCoreThreadTimeOut、keepAliveTime以及執行緒死亡
在上面的interruptIdleWorkers方法中，執行緒被中斷。普通的執行緒被中斷會導致執行緒繼續執行，從而run方法執行完畢，執行緒退出。
對於一個沒有被阻塞的執行緒，中斷是不起作用的。中斷在如下執行緒被阻塞的方法中起作用：
the wait(),
wait(long),
wait(long, int)
join(),
join(long),
join(long, int),
sleep(long),
or sleep(long, int)
LockSupport.park(Object object);
LockSupport.park();
，如果喚醒這些被阻塞的執行緒，從而能使得run方法繼續執行，當run方法執行完畢，那麼執行緒也就終結死亡。但是對於ReentrantLock和AbstractQueuedSynchronizer這種自旋+CAS實現的“邏輯鎖”，是不起作用的。
而且runWork本身也是While迴圈，靠中斷是無法退出迴圈的。
但是在ThreadPoolExecutor的建構函式中，有一個允許設定執行緒超時allowCoreThreadTimeOut引數的方法。如果允許超時，多於corePoolSize的執行緒將會在處在空閒狀態之後存活keepAliveTime時長後終止。因此有了一個allowCoreThreadTimeOut方法：
public void allowCoreThreadTimeOut(boolean value) {
if (value && keepAliveTime <= 0)
throw new IllegalArgumentException("Core threads must have nonzero keep alive times");
if (value != allowCoreThreadTimeOut) {
allowCoreThreadTimeOut = value;
if (value)
interruptIdleWorkers();
}
}
正如上面提到的一樣，允許allowCoreThreadTimeOut並且呼叫interruptIdleWorkers方法並不能使執行緒退出。那麼執行緒池又如何殺掉這個執行緒呢？
沒錯，就是getTask方法。只有當getTask返回null的時候才能跳出While迴圈，run方法執行完畢，那麼執行緒自然而然就死亡了。getTask方法如下所示：
private Runnable getTask() {
boolean timedOut = false; // Did the last poll() time out?
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
int wc = workerCountOf(c);
// Are workers subject to culling?
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
if ((wc > maximumPoolSize || (timed && timedOut))
&& (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
Runnable r = timed ?
workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}
可以看到，如果執行緒池狀態大於SHUTDOWN並且佇列空，返回null，從而結束迴圈。（執行緒死亡）
或者狀態大於SHUTDOWN並且執行緒大於STOP（STOP一定大於SHUTDOWN，所以可以直接說執行緒大於STOP）返回null，從而結束迴圈。（執行緒死亡）
再往下可以看到如果超過了maximumPoolSize，返回null，從而結束迴圈。（執行緒死亡）
超過keepAliveTime時間，任務對列沒有資料而返回null。從而結束迴圈。（執行緒死亡）boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;保證了執行緒池至少留下corePoolSize個執行緒。
預定義的拒接處理協議
在execute方法中，如果執行緒池拒絕新增任務，就會有一個鉤子方法來處理被拒絕的任務。
可以自己定義，也可以使用線城池中預設的拒接處理協議。
AbortPolicy :直接丟擲RejectedExecutionException異常；
CallerRunsPolicy：誰呼叫的execute方法，誰就執行這個任務；
DiscardPolicy:直接丟棄，什麼也不做；
DiscardOldestPolicy：丟棄對列中間最老的任務，執行新任務。
有什麼問題或者建議，可以加入小密圈和我一起討論，或者在簡書留言，歡迎喜歡和打賞。
本書節選自：Java併發程式設計系統與模型，個人覺得寫得不錯，比較通俗易懂，非常適合初學者，百度閱讀可以下載電子書。
相關文章
- Java核心（二）深入理解執行緒池ThreadPoolJava執行緒thread
- iOS 深入剖析多執行緒iOS執行緒
- ThreadPool執行緒池thread執行緒
- Java執行緒池核心原理剖析Java執行緒
- Flink 叢集執行原理兼部署及Yarn執行模式深入剖析-Flink牛刀小試Yarn模式
- 深入理解Promise執行原理Promise
- Clojure 執行原理之編譯器剖析編譯
- 資料塊原理深入剖析
- 溫故知新-多執行緒-深入剖析AQS執行緒AQS
- [深入學習C#]C#實現多執行緒的方法：執行緒(Thread類)和執行緒池(ThreadPool)C#執行緒thread
- 深入學習執行緒池原理執行緒
- 萬字剖析Ribbon核心元件以及執行原理元件
- 深入wepy原始碼：wepy執行原理分析原始碼
- 以 DEBUG 方式深入理解執行緒的底層執行原理執行緒
- Java-ThreadPool執行緒池總結Javathread執行緒
- Java執行緒池ThreadPoolExecutor實現原理剖析 #28Java執行緒thread
- 剖析react核心設計原理--非同步執行排程React非同步
- 深入Java原始碼理解執行緒池原理Java原始碼執行緒
- 深入理解執行緒池原理篇執行緒
- 深入分析 Redis Lua 指令碼執行原理Redis指令碼
- 深入淺出MyBatis：MyBatis解析和執行原理MyBatis
- 轉：Tomcat執行緒池apr和threadPoolTomcat執行緒thread
- 深入剖析Redis客戶端Jedis的特性和原理Redis客戶端
- 【SpringCloud原理】Ribbon核心元件以及執行原理萬字原始碼剖析SpringGCCloud元件原始碼
- 深入理解多執行緒（一）——Synchronized的實現原理執行緒synchronized
- 深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 – 掌握 CGI 和 FastCGI 協議的執行原理Web伺服器PHPAST協議
- 深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 - 掌握 CGI 和 FastCGI 協議的執行原理Web伺服器PHPAST協議
- Laravel 核心--深入剖析 Laravel 框架 Jwt 元件的實現原理Laravel框架JWT元件
- 深入原始碼，深度解析Java 執行緒池的實現原理原始碼Java執行緒
- Spark的執行原理Spark
- HDFS的執行原理
- 深入剖析 Laravel 服務提供者實現原理Laravel
- 《java學習三》併發程式設計 -------執行緒池原理剖析Java程式設計執行緒
- 阿里大佬帶你，深入理解執行緒池底層原理阿里執行緒
- JavaScript入門③-函式(2)原理{深入}執行上下文JavaScript函式
- rust 實戰 - 實現一個執行緒工作池 ThreadPoolRust執行緒thread
- 剖析SQL語句的執行過程SQL
- 深入剖析KafkaKafka