码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2014-08-29 00:10:16      阅读:332      评论:0      收藏:0      [点我收藏+]

标签: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。

 

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

标签:threadpoolexecutor源码   execute方法的巧妙设计   

原文地址:http://blog.csdn.net/aitangyong/article/details/38842643

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!