理解ThreadPoolExecutor源代码(二)execute函数的巧妙设计和阅读心得

ThreadPoolExecutor.execute()源代码提供了大量凝视来解释该方法的设计考虑。以下的源代码来自jdk1.6.0_37

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
            if (runState == RUNNING && workQueue.offer(command)) {
                if (runState != RUNNING || poolSize == 0)
                    ensureQueuedTaskHandled(command);
            }
            else if (!addIfUnderMaximumPoolSize(command))
                reject(command); // is shutdown or saturated
        }
    }

使用这么多if-else就是为了性能考虑，减小锁的使用范围，避免execute方法整个运行过程中都持有mainLock锁。可以看到仅仅有调用addIfUnderCorePoolSize、ensureQueuedTaskHandled、addIfUnderMaximumPoolSize这3个方法才须要持有锁。假设新提交的任务。不会进入这3个方法。那么就不须要持有锁。我们来看下。execute方法的设计是否可以有效地降低进入这3个方法的次数，实现快进快出。

第4行代码poolSize >= corePoolSize。为什么要加这个推断呢？

假设通过prestartAllCoreThreads事先启动了全部核心线程，或者是提交的任务已经让当前大小poolSize达到了核心大小 corePoolSize，而且核心线程不会死亡（allowCoreThreadTimeOut=false不同意核心线程超时退出。而且任务运行过程没有抛出异常导致线程退出），那么线程池中的线程数一定不会比corePoolSize小。此后假设再提交新任务。那么就不会进入addIfUnderCorePoolSize方法。poolSize
>= corePoolSize就是为了降低进入addIfUnderCorePoolSize函数的次数，降低锁的获取和释放次数。假设poolSize<corePoolSize，那么就会进入addIfUnderCorePoolSize。该方法会在加锁情况下。推断线程池的状态和当前大小，然后决定是否须要新加线程来处理任务。因为addIfUnderCorePoolSize会持有mainLock锁，所以能够防止其它线程对线程池的并发改动。也就说能够保证：在不须要加入新线程的时候，就不会加入。The
call to addIfUnderCorePoolSize rechecks runState and pool size under lock (they change only under lock) so prevents false alarms that would add threads when it shouldn't。源代码中这段凝视，说的就是这个效果。

第5行代码if (runState == RUNNING && workQueue.offer(command))，假设程序能走到这行代码。从任务提交者的角度来看，此时线程池大小已经达到了核心大小（尽管事实情况不一定如此，由于没有加锁，存在并发改动的可能。并且线程池中的线程也可能会死亡。假设满足条件：

runState == RUNNING && workQueue.offer(command) 这意味着：线程池仍然处于执行状态，而且任务排队已经成功。

为什么程序执行到这里依旧不能结束，还是须要走之后的代码呢？由于没有加锁，推断条件不一定可靠。

考虑以下2个场景：假设任务刚開始调用offer(还没有成功地插入到堵塞队列中)。线程池中的线程所有死亡，那么就没有线程来处理当前提交的这个任务了。假设任务刚刚排队成功。别的线程调用了shutdownNow()关闭了线程池。那么依照shutdownNow函数的语义，这个任务不应该被处理。

由于存在这2种特殊情况。所以必须进行兴许的处理。but
may also fail to add them when they should. This is compensated within the following steps.这就是说：addIfUnderCorePoolSize可以保证不须要新线程的时候就不加入。可是不能保证须要加入新线程的时候就加入。所以让任务排队成功的时候。须要在锁的保护下，推断是否须要删除这个任务，或者是否须要新增线程来处理任务。

第6行代码if (runState != RUNNING || poolSize == 0)，假设任务成功排队(workQueue.offer()返回true)后，线程池被关闭或者没有存活的线程，那么就须要执行ensureQueuedTaskHandled(command)。也就是说这样的情况下。任务可能没有得到合适的处置。

假设任务成功排队后，线程池仍然处在执行状态，并且有存活的线程。那么就行确保该新提交的任务一定会被处理。

为什么会这样呢？我们知道假设想关闭ThreadPoolExecutor，仅仅有3种途径：调用shutdown方法。调用shutdownNow方法，线程池最后一个工作者退出(相应workerDone方法)。

查看源代码我们知道，这3个可能导致线程池关闭的方法，终于都会调用tryTerminate()方法。也就是说假设线程池想要终止，就必须通过该方法。

/**
     * Transitions to TERMINATED state if either (SHUTDOWN and pool
     * and queue empty) or (STOP and pool empty), otherwise unless
     * stopped, ensuring that there is at least one live thread to
     * handle queued tasks.
     *
     * This method is called from the three places in which
     * termination can occur: in workerDone on exit of the last thread
     * after pool has been shut down, or directly within calls to
     * shutdown or shutdownNow, if there are no live threads.
     */
    private void tryTerminate() {
        if (poolSize == 0) {
            int state = runState;
            if (state < STOP && !workQueue.isEmpty()) {
                state = RUNNING; // disable termination check below
                Thread t = addThread(null);
                if (t != null)
                    t.start();
            }
            if (state == STOP || state == SHUTDOWN) {
                runState = TERMINATED;
                termination.signalAll();
                terminated();
            }
        }
    }

当线程池的线程池数是0的时候。假设线程池是running或者shutdown状态，而且任务队列不为空，那么就会新增1个线程来处理任务；假设线程池是状态，或者处于shutdown状态而且任务队列为空。那么线程池就会退出。也就是说，假设任务排队成功后，线程池还没有终止，那么该任务一定会得到合理的处置。

假设在任务插入之前或者插入的过程中。线程池不在执行状态runState != RUNNING 或者没有存活的线程poolSize == 0，那么就须要自己考虑下：怎样处理该提交的任务。这通过ensureQueuedTaskHandled来完毕。假设if (runState == RUNNING && workQueue.offer(command))条件是真，那么随后if (runState != RUNNING || poolSize == 0)基本上非常少出现。大部分场景下都不须要执行ensureQueuedTaskHandled方法，就不须要获取和释放锁。以下我们通过源代码看下，ensureQueuedTaskHandled方法是怎样处理异常场景的。

/**
     * Rechecks state after queuing a task. Called from execute when
     * pool state has been observed to change after queuing a task. If
     * the task was queued concurrently with a call to shutdownNow,
     * and is still present in the queue, this task must be removed
     * and rejected to preserve shutdownNow guarantees.  Otherwise,
     * this method ensures (unless addThread fails) that there is at
     * least one live thread to handle this task
     * @param command the task
     */
    private void ensureQueuedTaskHandled(Runnable command) {
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        boolean reject = false;
        Thread t = null;
        try {
            int state = runState;
            if (state != RUNNING && workQueue.remove(command))
                reject = true;
            else if (state < STOP &&
                     poolSize < Math.max(corePoolSize, 1) &&
                     !workQueue.isEmpty())
                t = addThread(null);
        } finally {
            mainLock.unlock();
        }
        if (reject)
            reject(command);
        else if (t != null)
            t.start();
    }

该方法持有mainLock锁。所以能够防止线程池的并发改动。

假设线程池不在running状态（state != RUNNING ），而且新提交的任务还驻留在任务队列中（workQueue.remove(command)返回true），那么当前提交的任务会被拒绝运行（调用reject(comma)方法）。也就是说。仅仅要线程池不是running状态，那么就一定会拒绝运行当前提交的任务，除非该任务已经被线程池中的线程处理了(workQueue.remove返回false)。这里不区分究竟是shutdown()关闭的线程池。还是通过shutdownNow关闭的线程池。假设新提交一个任务，而且运行流程进入了ensureQueuedTaskHandled()函数。那么该任务可能会被拒绝运行。也可能会被正常运行。

假设线程池是running或者shutdown状态（state
< STOP）。而且线程池中已经没有存活的线程，而且任务队列非空。那么就须要新加1个线程，来处理等待运行的任务。

可以看到：通过多次无锁的条件推断，可以有效地降低提交任务时对mainLock锁的竞争；也可以确在并发运行的情况下。当前新提交的任务和线程池中等待运行的任务，都能得到合适的处理。

不知道大师Doug Lea是怎样想到这么巧妙的设计和实现execute()方法的！尽管execute方法可以提高性能，可是牺牲了代码的可读性和简易性。对于并发程序，还是那句经典的老话make it right before
you make it faster。