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。