刨根問底（二）：ThreadPoolExecutor

一、什麼是ThreadPoolExecutor

ThreadPoolExecutor是Java 1.5開始引入的，作為執行緒存放的集合池子——執行緒池，主要是為了解決：

1. 重用執行緒資源，降低執行緒建立和銷燬的開銷；
2. 集中維護和管理多個執行緒；

二、編碼體驗

JDK已經為我們封裝好了執行緒池的工具類Executors，提供了幾個便利的靜態方法，簡單列舉幾個；

1. newFixedThreadPool：定長執行緒池；
2. newSingleThreadExecutor：單執行緒的執行緒池；
3. newCachedThreadPool：可快取的執行緒池；
4. newScheduledThreadPool：可延遲執行或週期執行執行緒池；

這裡採用newFixedThreadPool作為例子，兩種執行緒池提交方式為例：

ExecutorService service = Executors.newFixedThreadPool(1);
service.submit(() -> System.out.println("submit提交，開啟多執行緒..."));
service.execute(() -> System.out.println("execute提交，開啟多執行緒..."));

這樣就建立了長度為1的執行緒池，並且分別用submit和execute兩種方式提交了任務，可以看出不需要我們手動new新的執行緒，也不需要我們手動start執行緒。

三、原始碼剖析

為什麼定義好了執行緒池submit或execute了任務就可以自動執行，jdk底層又是如何實現的呢？

根據上面Executors的幾個靜態方法（除了newScheduledThreadPool），最終都是指向ThreadPoolExecutor的構造方法：

1、構造方法

/**
 * Creates a new {@code ThreadPoolExecutor} with the given initial
 * parameters.
 *
 * @param corePoolSize the number of threads to keep in the pool, even
 *        if they are idle, unless {@code allowCoreThreadTimeOut} is set
 * @param maximumPoolSize the maximum number of threads to allow in the
 *        pool
 * @param keepAliveTime when the number of threads is greater than
 *        the core, this is the maximum time that excess idle threads
 *        will wait for new tasks before terminating.
 * @param unit the time unit for the {@code keepAliveTime} argument
 * @param workQueue the queue to use for holding tasks before they are
 *        executed.  This queue will hold only the {@code Runnable}
 *        tasks submitted by the {@code execute} method.
 * @param threadFactory the factory to use when the executor
 *        creates a new thread
 * @param handler the handler to use when execution is blocked
 *        because the thread bounds and queue capacities are reached
 * @throws IllegalArgumentException if one of the following holds:<br>
 *         {@code corePoolSize < 0}<br>
 *         {@code keepAliveTime < 0}<br>
 *         {@code maximumPoolSize <= 0}<br>
 *         {@code maximumPoolSize < corePoolSize}
 * @throws NullPointerException if {@code workQueue}
 *         or {@code threadFactory} or {@code handler} is null
 */
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;
}

構造方法的引數還是比較多的，根據原始碼註釋逐個分析：

1. corePoolSize
   核心執行緒數，除非設定了allowCoreThreadTimeOut，否則需要保留在池中的執行緒數大小，即使這些執行緒處於空閒狀態；

2. maximumPoolSize
   允許執行緒池中最大的執行緒數量；

3. keepAliveTime
   當執行緒數量超過了核心執行緒數，多出閒置的執行緒在等待新任務的最長時間；

4. unit
   keepAliveTime的時間單位；

5. workQueue
   執行任務前用於儲存任務的佇列，該佇列僅僅包含提交的Runnable的任務；

6. threadFactory
   executor建立新執行緒使用的執行緒工廠；

7. handler
   執行緒池飽和處理策略；

構造方法具體只是做了引數非空校驗，以及全域性變數的初始化，接下來看看execute方法：

2、execute

/**
 * Executes the given task sometime in the future.  The task
 * may execute in a new thread or in an existing pooled thread.
 *
 * If the task cannot be submitted for execution, either because this
 * executor has been shutdown or because its capacity has been reached,
 * the task is handled by the current {@code RejectedExecutionHandler}.
 *
 * @param command the task to execute
 * @throws RejectedExecutionException at discretion of
 *         {@code RejectedExecutionHandler}, if the task
 *         cannot be accepted for execution
 * @throws NullPointerException if {@code command} is null
 */
public void execute(Runnable command) {
    if (command == null)
        throw new NullPointerException();
    /*
     * Proceed in 3 steps:
     *
     * 1. If fewer than corePoolSize threads are running, try to
     * start a new thread with the given command as its first
     * task.  The call to addWorker atomically checks runState and
     * workerCount, and so prevents false alarms that would add
     * threads when it shouldn't, by returning false.
     *
     * 2. If a task can be successfully queued, then we still need
     * to double-check whether we should have added a thread
     * (because existing ones died since last checking) or that
     * the pool shut down since entry into this method. So we
     * recheck state and if necessary roll back the enqueuing if
     * stopped, or start a new thread if there are none.
     *
     * 3. If we cannot queue task, then we try to add a new
     * thread.  If it fails, we know we are shut down or saturated
     * and so reject the task.
     */
    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);
}

原始碼註釋已經說明得很清楚，執行緒池工作流程分為3步：

1. 如果當前執行緒池的執行緒數量小於corePoolSize，那麼嘗試新建一個執行緒執行該任務，會通過檢查當前狀態runState和執行緒池執行緒數量workerCount來進行原子操作addWorker，根據返回值決定操作成功與否；
2. 否則檢查當前任務是否可以排隊（大於corePoolSize，小於maximumPoolSize），就算確認可以新增到workQueue中排隊等待，我們還是需要recheck重新檢查當先執行緒池狀態，可能由於之前的工作執行緒已經died或者當前執行緒池shutdown；
3. 如果當前任務都無法排隊（等待佇列已滿），那麼嘗試新建一個執行緒執行該任務，如果仍然失敗（執行緒池數量大於maximumPoolSize），那麼執行拒絕策略reject；

執行邏輯還是比較複雜的，因為新增佇列、修改狀態均使用了無鎖原子操作，附以圖示：

ok，回到execute方法原始碼來，特別注意這個全域性變數ctl，她便是執行緒池的資料核心。

3、ctl

/**
 * The main pool control state, ctl, is an atomic integer packing
 * two conceptual fields
 *   workerCount, indicating the effective number of threads
 *   runState,    indicating whether running, shutting down etc
 *
 * In order to pack them into one int, we limit workerCount to
 * (2^29)-1 (about 500 million) threads rather than (2^31)-1 (2
 * billion) otherwise representable. If this is ever an issue in
 * the future, the variable can be changed to be an AtomicLong,
 * and the shift/mask constants below adjusted. But until the need
 * arises, this code is a bit faster and simpler using an int.
 *
 * The workerCount is the number of workers that have been
 * permitted to start and not permitted to stop.  The value may be
 * transiently different from the actual number of live threads,
 * for example when a ThreadFactory fails to create a thread when
 * asked, and when exiting threads are still performing
 * bookkeeping before terminating. The user-visible pool size is
 * reported as the current size of the workers set.
 *
 * The runState provides the main lifecycle control, taking on values:
 *
 *   RUNNING:  Accept new tasks and process queued tasks
 *   SHUTDOWN: Don't accept new tasks, but process queued tasks
 *   STOP:     Don't accept new tasks, don't process queued tasks,
 *             and interrupt in-progress tasks
 *   TIDYING:  All tasks have terminated, workerCount is zero,
 *             the thread transitioning to state TIDYING
 *             will run the terminated() hook method
 *   TERMINATED: terminated() has completed
 *
 * The numerical order among these values matters, to allow
 * ordered comparisons. The runState monotonically increases over
 * time, but need not hit each state. The transitions are:
 *
 * RUNNING -> SHUTDOWN
 *    On invocation of shutdown(), perhaps implicitly in finalize()
 * (RUNNING or SHUTDOWN) -> STOP
 *    On invocation of shutdownNow()
 * SHUTDOWN -> TIDYING
 *    When both queue and pool are empty
 * STOP -> TIDYING
 *    When pool is empty
 * TIDYING -> TERMINATED
 *    When the terminated() hook method has completed
 *
 * Threads waiting in awaitTermination() will return when the
 * state reaches TERMINATED.
 *
 * Detecting the transition from SHUTDOWN to TIDYING is less
 * straightforward than you'd like because the queue may become
 * empty after non-empty and vice versa during SHUTDOWN state, but
 * we can only terminate if, after seeing that it is empty, we see
 * that workerCount is 0 (which sometimes entails a recheck -- see
 * below).
 */
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int CAPACITY   = (1 << COUNT_BITS) - 1;

// runState is stored in the high-order bits
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;

// Packing and unpacking ctl
private static int runStateOf(int c)     { return c & ~CAPACITY; }
private static int workerCountOf(int c)  { return c & CAPACITY; }
private static int ctlOf(int rs, int wc) { return rs | wc; }

第一句話就概括了ctl，The main pool control state, ctl, is an atomic integer packing two conceptual fields，workerCount，runState。這個AtomicInteger型別的變數，儲存了工作執行緒數量和執行緒池狀態兩類資料，那麼是怎麼打包到一個變數中呢？

後面也有解釋說明，In order to pack them into one int, we limit workerCount to (2^29)-1 (about 500 million) threads rather than (2^31)-1 (2 billion) otherwise representable，int型別為32位，低29位用於儲存workCount而不是全部位數，高3位便用於儲存runState。

先用二級製表示出CAPACITY的儲存：

0001 1111 1111 1111 1111 1111 1111 1111

然後舉個例子，一個RUNNING的執行緒池有5個工作執行緒，那麼用ctl來表示為：

1110 0000 0000 0000 0000 0000 0000 0101

再回來看runStateOf()和workerCountOf()、ctlOf()三個方法，變得清晰多了。

既然已經清楚了ctl的工作原理，那麼回到execute原始碼，分析下新增任務addWorker方法原理。

4、addWorker

/*
 * Methods for creating, running and cleaning up after workers
 */

/**
 * Checks if a new worker can be added with respect to current
 * pool state and the given bound (either core or maximum). If so,
 * the worker count is adjusted accordingly, and, if possible, a
 * new worker is created and started, running firstTask as its
 * first task. This method returns false if the pool is stopped or
 * eligible to shut down. It also returns false if the thread
 * factory fails to create a thread when asked.  If the thread
 * creation fails, either due to the thread factory returning
 * null, or due to an exception (typically OutOfMemoryError in
 * Thread.start()), we roll back cleanly.
 *
 * @param firstTask the task the new thread should run first (or
 * null if none). Workers are created with an initial first task
 * (in method execute()) to bypass queuing when there are fewer
 * than corePoolSize threads (in which case we always start one),
 * or when the queue is full (in which case we must bypass queue).
 * Initially idle threads are usually created via
 * prestartCoreThread or to replace other dying workers.
 *
 * @param core if true use corePoolSize as bound, else
 * maximumPoolSize. (A boolean indicator is used here rather than a
 * value to ensure reads of fresh values after checking other pool
 * state).
 * @return true if successful
 */
private boolean addWorker(Runnable firstTask, boolean core) {
    retry:
    for (;;) {
        int c = ctl.get();
        int rs = runStateOf(c);

        // Check if queue empty only if necessary.
        if (rs >= SHUTDOWN &&
            ! (rs == SHUTDOWN &&
               firstTask == null &&
               ! workQueue.isEmpty()))
            return 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;
}

原始碼有點長，但我還是全部貼出來了，方便後續整體回顧，細細品讀還是別有一番滋味，下面逐段分析下。

開頭定義了一個標籤retry，用於內層巢狀for迴圈的控制，然後是一段簡單的校驗邏輯，對當前執行緒池狀態、提交的任務及阻塞佇列進行校驗；

// Check if queue empty only if necessary.
if (rs >= SHUTDOWN &&
    ! (rs == SHUTDOWN &&
       firstTask == null &&
       ! workQueue.isEmpty()))
    return false;

然後是無限迴圈CAS增加workerCount，很有意思的一段程式碼；

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
}

當CAS執行成功，即break到開頭的retry標籤，進行後面的操作。否則的話，說明執行期間ctl發生了改變，那麼重新獲取ctl，並且判斷當前狀態是否改變。如果runState沒有改變繼續執行內層for迴圈，沒有必要執行外層迴圈初始化變數和引數校驗邏輯，如果改變了就continue到retry標籤，完全重來一次。

當CAS成功後，代表當前執行緒池workerCount已經增加了，那麼現在便需要建立新的執行緒來執行了：

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;

注意這裡兩個finnaly，第一個是ReetrantLock的釋放，第二個是addWorker的校驗回滾，當出現執行緒池shutdown，或者是新建的執行緒非存活狀態，都需要回滾之前增加workerCount的操作，也就是之前CAS的操作，否則便start啟動建立的執行緒並初始化兩個bool標識位，附上addWorkerFailed的原始碼：

/**
 * Rolls back the worker thread creation.
 * - removes worker from workers, if present
 * - decrements worker count
 * - rechecks for termination, in case the existence of this
 *   worker was holding up termination
 */
private void addWorkerFailed(Worker w) {
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    try {
        if (w != null)
            workers.remove(w);
        decrementWorkerCount();
        tryTerminate();
    } finally {
        mainLock.unlock();
    }
}

有必要看下workers的定義了；

/**
 * Set containing all worker threads in pool. Accessed only when
 * holding mainLock.
 */
private final HashSet<Worker> workers = new HashSet<Worker>();

Set containing all worker threads in pool. Accessed only when holding mainLock.執行緒池中所有工作執行緒的集合，只有在持有mainLock鎖的情況下才能訪問該workers。這也就印證了每次對workers的操作，都需要獲取鎖mainLock.lock();了。

5、Worker

/**
 * Class Worker mainly maintains interrupt control state for
 * threads running tasks, along with other minor bookkeeping.
 * This class opportunistically extends AbstractQueuedSynchronizer
 * to simplify acquiring and releasing a lock surrounding each
 * task execution.  This protects against interrupts that are
 * intended to wake up a worker thread waiting for a task from
 * instead interrupting a task being run.  We implement a simple
 * non-reentrant mutual exclusion lock rather than use
 * ReentrantLock because we do not want worker tasks to be able to
 * reacquire the lock when they invoke pool control methods like
 * setCorePoolSize.  Additionally, to suppress interrupts until
 * the thread actually starts running tasks, we initialize lock
 * state to a negative value, and clear it upon start (in
 * runWorker).
 */
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;

    /** Thread this worker is running in.  Null if factory fails. */
    final Thread thread;
    /** Initial task to run.  Possibly null. */
    Runnable firstTask;
    /** Per-thread task counter */
    volatile long completedTasks;

    /**
     * Creates with given first task and thread from ThreadFactory.
     * @param firstTask the first task (null if none)
     */
    Worker(Runnable firstTask) {
        setState(-1); // inhibit interrupts until runWorker
        this.firstTask = firstTask;
        this.thread = getThreadFactory().newThread(this);
    }

    /** Delegates main run loop to outer runWorker  */
    public void run() {
        runWorker(this);
    }

    // Lock methods
    //
    // The value 0 represents the unlocked state.
    // The value 1 represents the locked state.

    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) {
            }
        }
    }
}

可以看到Worker類是ThreadPoolExecutor的內部類，並且實現了Runnable介面，繼承自AbstractQueuedSynchronizer，仔細看她的構造方法，將自己的例項作為引數執行this.thread = getThreadFactory.newThread(this);，所以結合之前的addWorker方法中，執行t.start();，因此實際就是觸發的Worker的run方法也就是外層runWorker方法（ThreadPoolExecutor的方法）；

理所當然，這個runWorker方法，才是執行緒池中執行緒執行的核心；

6、runWorker

/**
 * Main worker run loop.  Repeatedly gets tasks from queue and
 * executes them, while coping with a number of issues:
 *
 * 1. We may start out with an initial task, in which case we
 * don't need to get the first one. Otherwise, as long as pool is
 * running, we get tasks from getTask. If it returns null then the
 * worker exits due to changed pool state or configuration
 * parameters.  Other exits result from exception throws in
 * external code, in which case completedAbruptly holds, which
 * usually leads processWorkerExit to replace this thread.
 *
 * 2. Before running any task, the lock is acquired to prevent
 * other pool interrupts while the task is executing, and then we
 * ensure that unless pool is stopping, this thread does not have
 * its interrupt set.
 *
 * 3. Each task run is preceded by a call to beforeExecute, which
 * might throw an exception, in which case we cause thread to die
 * (breaking loop with completedAbruptly true) without processing
 * the task.
 *
 * 4. Assuming beforeExecute completes normally, we run the task,
 * gathering any of its thrown exceptions to send to afterExecute.
 * We separately handle RuntimeException, Error (both of which the
 * specs guarantee that we trap) and arbitrary Throwables.
 * Because we cannot rethrow Throwables within Runnable.run, we
 * wrap them within Errors on the way out (to the thread's
 * UncaughtExceptionHandler).  Any thrown exception also
 * conservatively causes thread to die.
 *
 * 5. After task.run completes, we call afterExecute, which may
 * also throw an exception, which will also cause thread to
 * die. According to JLS Sec 14.20, this exception is the one that
 * will be in effect even if task.run throws.
 *
 * The net effect of the exception mechanics is that afterExecute
 * and the thread's UncaughtExceptionHandler have as accurate
 * information as we can provide about any problems encountered by
 * user code.
 *
 * @param w the worker
 */
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 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
            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);
    }
}

Main worker run loop. Repeatedly gets tasks from queue and executes them, while coping with a number of issues，主要Worker進行迴圈，重複從佇列中獲取task任務並執行她們，同時處理一些問題；

值得注意的是這裡task.run();前後兩個處理方法beforeExecute(wt, task);和afterExecute(task, thrown);，都是兩個空的方法，方便我們自定義執行緒池進行擴充；

其實看到這裡還沒有涉及到等待佇列queue的資料互動，但是沒關係，結合前面execute方法的解析，也有個一知半解，這裡task執行完並不會結束該執行緒，而是會從queue中獲取等待的task，while (task != null || (task = getTask()) != null)，第一個條件當然是worker本身的task任務，後面肯定是從佇列中獲取task了；

7、getTask

/**
 * Performs blocking or timed wait for a task, depending on
 * current configuration settings, or returns null if this worker
 * must exit because of any of:
 * 1. There are more than maximumPoolSize workers (due to
 *    a call to setMaximumPoolSize).
 * 2. The pool is stopped.
 * 3. The pool is shutdown and the queue is empty.
 * 4. This worker timed out waiting for a task, and timed-out
 *    workers are subject to termination (that is,
 *    {@code allowCoreThreadTimeOut || workerCount > corePoolSize})
 *    both before and after the timed wait, and if the queue is
 *    non-empty, this worker is not the last thread in the pool.
 *
 * @return task, or null if the worker must exit, in which case
 *         workerCount is decremented
 */
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;
        }
    }
}

這裡有一行比較關鍵：

// Are workers subject to culling?
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

這個timed的值直接決定後面workQueue取值的方式，是採用poll還是take，區別便是前者具有佇列取值可以指定阻塞await時長，而後者一直阻塞await等待，貼一段LinkedBlockingQueue的poll的程式碼；

public E poll(long timeout, TimeUnit unit) throws InterruptedException {
    E x = null;
    int c = -1;
    long nanos = unit.toNanos(timeout);
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lockInterruptibly();
    try {
        while (count.get() == 0) {
            if (nanos <= 0)
                return null;
            nanos = notEmpty.awaitNanos(nanos);
        }
        x = dequeue();
        c = count.getAndDecrement();
        if (c > 1)
            notEmpty.signal();
    } finally {
        takeLock.unlock();
    }
    if (c == capacity)
        signalNotFull();
    return x;
}

注意到while迴圈體裡面的nanos = notEmpty.awaitNanos(nanos);，結合之前timed的定義，就知道執行緒池裡面工作執行緒的生命週期了，當allowCoreThreadTimeOut || wc > corePoolSize為true是，該執行緒會從workQueue中取值並指定等待時長即構造方法中的keepAliveTime，超過該時長還是取不到task的話，getTask返回null，結束runWorker的while迴圈，執行緒結束；

順便提及一句allowCoreThreadTimeOut預設是false，可以通過ThreadPoolExecutor的allowCoreThreadTimeOut方法修改預設值；

8、execute

分析到這裡，也就差不多弄清楚了execute方法的第一步，但也是最重要的一步，接著execute方法來看，後面就變得簡單多了，為了方便翻閱，重貼下execute方法（需要看原始碼註釋的往上翻 ↑）；

public void execute(Runnable command) {
    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);
}

若當前workerCount已經超過了corePoolSize，那麼會執行到下面的入隊offer操作，offer的返回值說明是否入隊成功，取決於等待佇列workQueue是否容量已滿，然而Executors提供的好幾個靜態工廠生成的ThreadPoolExecutor的阻塞佇列，都是new LinkedBlockingQueue<Runnable>()，貼下LinkedBlockingQueue的構造方法；

/**
 * Creates a {@code LinkedBlockingQueue} with a capacity of
 * {@link Integer#MAX_VALUE}.
 */
public LinkedBlockingQueue() {
    this(Integer.MAX_VALUE);
}

/**
 * Creates a {@code LinkedBlockingQueue} with the given (fixed) capacity.
 *
 * @param capacity the capacity of this queue
 * @throws IllegalArgumentException if {@code capacity} is not greater
 *         than zero
 */
public LinkedBlockingQueue(int capacity) {
    if (capacity <= 0) throw new IllegalArgumentException();
    this.capacity = capacity;
    last = head = new Node<E>(null);
}

預設容量是Integer.MAX_VALUE，也就是(2^31) - 1，所以這個預設阻塞佇列有點難滿，所以阿里Java規範也推薦手寫執行緒池構造引數，加深理解；

回到上面execute流程，入隊之後還做了一次recheck，這個recheck兩個條件非常有必要，一是判斷當前執行緒池狀態，而是判斷當前工作執行緒數是否為0，分別進行對應處理；

最後如果的確是佇列已滿，則繼續執行addWorker方法，區別是傳入的第二個引數為false，這個決定了workerCount的邊界，是corePoolSize還是maximumPoolSize，若仍然執行失敗則會進行reject處理，最後貼一下ThreadPoolExecutor預設的handler；

/**
 * A handler for rejected tasks that throws a
 * {@code RejectedExecutionException}.
 */
public static class AbortPolicy implements RejectedExecutionHandler {
    /**
     * Creates an {@code AbortPolicy}.
     */
    public AbortPolicy() { }

    /**
     * Always throws RejectedExecutionException.
     *
     * @param r the runnable task requested to be executed
     * @param e the executor attempting to execute this task
     * @throws RejectedExecutionException always
     */
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        throw new RejectedExecutionException("Task " + r.toString() +
                                             " rejected from " +
                                             e.toString());
    }
}

預設會丟擲一個異常，當然我們也可以實現這個RejectedExecutionHandler介面進行我們reject的自定義需求。

四、結束語

其實很早就想到要寫一篇執行緒池的原始碼分析，但由於各種原因寫到一半被擱置了很久。最近工作輕鬆不少，當我重新開始窺探Java的奧祕，還真的發自內心地感嘆起前輩們的思想，多麼的深邃遠見，自己積攢的不過是管中窺豹。

文章的編寫順序與自己翻閱原始碼的過程完全一致，就算一次性通讀全文，也不會感覺到太大的思想跳躍。而且本著刨根問底的思想，我儘可能地貼出對應完整的原始碼，不會因為相關注釋過長便落下。恰巧是這些原始碼中的註釋，才是我覺得理解原始碼的最好幫助。