线程池ThreadPoolExecutor的源码中是如何解决并发问题的？

置顶程序世界的王子

已于 2023-10-19 15:42:35 修改

阅读量2.1k

点赞数 26

分类专栏： java 文章标签： java java-ee 线程池

于 2023-01-01 18:21:30 首次发布

本文链接：https://blog.csdn.net/weixin_43274704/article/details/128160297

版权

java 专栏收录该内容

10 篇文章 2 订阅

订阅专栏

ThreadPoolExecutor面临哪些线程安全问题

ThreadPoolExecutor俗称线程池，其作用不需多说。其实为高效并发而生的ThreadPoolExecutor自身也面临着很多线程安全问题，如果一个ThreadPoolExecutor对象被多个线程同时使用，则可能出现以下问题：

1、如何保证线程合法的创建？
线程合法的创建指两个方面，即线程在创建完成之前，一方面线程池的状态允许创建新线程，如果线程池的状态是RUNNING或者线程池的状态是shutdown而且任务队列不为空，均可以创建新线程；另一方面线程的数量也不得超过额定值，其中核心线程数不超过corePoolSize，最大线程数不超过maximumPoolSize。

线程池创建新线程需要经过下面的步骤：
①检查线程池的状态是否允许创建新线程；
②检查线程的数量是否合法；
③将标记线程数量的属性自增1；
④创建新线程并启动；
⑤新线程存入队列（ThreadPoolExecutor源码中使用了一个HashSet集合存储已有的线程）。

因为在并发环境下，线程池的状态和线程数量都在不断变化，甚至可能瞬息万变，所以完全有可能在第①步检查线程池状态合法之后，线程池的状态被其他用户改为STOP了，或者在进行完第②步检查线程数量合法之后，又有其他用户创建了新线程等情况。

要解决这个问题，最简单的方式就是使用一个synchronized关键字将从①到⑤步骤之间的代码全部加锁。这样确实可以保证线程安全，但是大量代码块被以悲观锁的方式加锁会带来严重的锁竞争，在高并发环境下会导致大量的线程被阻塞，影响线程池的运行效率。实际上线程池在解决这个问题上要比我们想象的聪明的多。

2、如何保证线程执行任务时不被中断
线程池中的线程不能在任务执行过程中被中断，但是如果线程正在执行任务时，线程池被外部调用了线程池的shutdown()方法来终止线程池，会会将线程池中的空闲线程进行一次中断。那么正在执行任务的线程是如何避免自己被中断的呢？

3、线程的数量如何确保准确
线程池ThreadPoolExecutor提供了getActiveCount();方法来获取当前活跃线程的数量。如果线程池中有A、B两个线程同时执行结束，都需要将活跃线程数量workerCount减1。那么就要进行3个步骤：
①从主存中读取workerCount的值
②对workerCount进行减1操作
③把workerCount重新刷新到主存
如果A线程进行第①和①步之后还没有进行第③步将新的值刷入主存，B线程也拿到了旧的活跃线程数量workerCount的值进行减1，那么就会造成2个线程结束了，workerCount的值只减去1的后果。这个问题如何去避免呢？

注：ThreadPoolExecutor源码中使用了一个AtomicInteger型的原子整型变量“ctl”来同时记录线程池的状态和线程数量，int型数据有32位，其高3位表示线程状态，低29位表示线程数量。因此无论是线程池状态还是线程数量的改变都是针对“ctl”属性进行操作，要获取线程池状态或线程数量也要解析“ctl”属性来获取。
这里使用workerCount只是为了方便描述，实际上在ThreadPoolExecutor源码中没有workerCount这个属性。

线程创建：乐观锁与悲观锁的结合

上文说到，线程创建的步骤较多，如果直接用synchronized等悲观锁的方式将线程创建的全过程加锁，将导致大量的锁竞争，在高并发环境下不适用。因此，ThreadPoolExecutor采用了乐观锁与悲观锁结合的方式来实现线程创建过程的线程安全。具体过程为我认为可以分为三大步，这部分的代码在线程池的addWorker(Runnable firstTask, boolean core)方法的中。

1、初步检查，检查线程池状态和线程数量是否允许创建新线程，检查OK后使用CAS将线程数量增加1，其具体过程为：

①获取线程池的状态并保存。
②检查取线程池状态，如果线程池状态为stop,tidying,terminated等，或者线程池状态为shutdown并且任务队列为空，直接返回false，不允许创建新线程。
③获取并检查取线程数量，如果线程数量超过额定，也返回false。核心线程数不超过corePoolSize，最大线程数不超过maximumPoolSize。
④使用原子性的CAS机制将线程数量增加1，这里CAS的对象是线程池中用于记录线程状态和线程数量的“ctl”属性。如果CAS成功，则说明在线程池状态和线程数量在第①步以后都未改变，则可以进入下一步创建线程了。
⑤如果CAS失败则说明线程池状态或者线程数量发生了改变。
⑥获取当前最新的线程池状态，和第①步保存的线程池状态比较，如果线程池的状态发生了改变，则回到第①步，重新从检查线程池状态开始。
⑦如果经过第⑥步发现线程池状态未变，则说明是线程数量改变了，则回到第③步重新检查线程数量。

总结一下，初步检查使用了失败重试机制，在检查过程中不加锁，只是在CAS修改“ctl”属性失败以后不断的循环重新检查，直到CAS成功或者检查到线程池已经不能创建新线程为止，这是一种乐观锁思想的实现。

初步检查过程
初步检查使用乐观锁机制来检查线程池状态和线程数量合法性，可以有效的避免锁竞争，减少线程因同步导致的阻塞，增加线程池的并发性能。线程阻塞属于重量级操作，因为挂起线程和恢复线程的操作都需要转入内核态完成。

其对应的代码块为：

       //设置一个标志位，以便检查成功跳出两层for循环
       retry:
        //两个for循环，外层循环检查线程池状态是否运行创建新线程
        for (;;) {
            int c = ctl.get();
            //获取线程池的状态并保存
            int rs = runStateOf(c);
            //下面开始检查线程池状态是否允许创建新线程
            //如果rs >= SHUTDOWN，说明线程池的状态是为 stop,tidying,terminated
            //如果线程池处于 shutdown，且 firstTask 为 null,同时队列不为空，允许创建 worker
            //如果线程池处于stop,tidying,terminated，均不允许创建worker
            if (rs >= SHUTDOWN &&
                    ! (rs == SHUTDOWN &&
                            firstTask == null &&
                            ! workQueue.isEmpty()))
                return false;
            //内层循环检查工作线程数量是否在要求范围之内
            for (;;) {
                //获取线程数量
                int wc = workerCountOf(c);
                //如果工作线程的数量超标，直接返回false
                if (wc >= CAPACITY ||
                        wc >= (core ? corePoolSize : maximumPoolSize))
                    return false;
                //compareAndIncrementWorkerCount方法的作用是先比较ctl的当前实际值有没有改变
                //没有改变的话将ctl自增1，然后进行下一步创建线程
                if (compareAndIncrementWorkerCount(c))
                    //跳出两层for循环，执行下面的正式创建线程的代码
                    break retry;
                //CAS修改失败，说明ctl的值改变了，因为ctl的值包含了线程池状态和线程数量，
                //所以其改变就有两种可能：线程数量被并发修改了，或者线程池状态都变了
                //获取线程池最新的状态
                c = ctl.get();
                //如果线程池的状态发生改变，则需要从头开始重新获取线程池状态，
                //即重新执行外部的大循环
                if (runStateOf(c) != rs)
                    continue retry;
                    //走到这里，说明线程池状态没变，那只能是工作线程数量变了，
                    //则只需要重新检查线程数量是否合适，即重新执行内部小循环
            }
        }

2、创建一个新线程。如果初次检查成功，则创建一个线程。但是需要注意的是，此时只是创建了线程实例，并没有调用线程的start()方法将线程启动。因为经过第1步虽然已经使用CAS完成了线程数量自增，所以不会再有线程数量超标的问题，但是线程池的状态仍然可能改变。

3、再次检查线程池状态。创建线程之后，线程池的状态还可能会被修改，所以在线程启动和加入队列之前需要使用悲观锁来上锁，防止线程池状态被修改。上锁之后再次检查线程池状态，检查通过之后start()方法启动线程并将线程加入队列，最后释放锁。
ThreadPoolExecutor源码中封装了一个ReentrantLock属性mainLock，用来给给再次检查的代码块加锁。当有其他用户调用线程池的shutdown()等方法改变线程池状态时，首先需要使用mainLock获取锁，才能修改线程池状态。ReentrantLock是一种悲观锁的实现，对获取不到锁的线程将进行阻塞等待。因此在第3步加锁之后，没有其他任何线程能改变线程池的状态，直到线程创建完成后释放锁。

    /*
    * 当线程对象创建之后，线程启动之前，需要再次检查线程池状态，为了防止此期间
    * 线程池状态被修改，需要用ReentrantLock来进行加锁。当有用户调用线程池的shutdown()
    * 等方法改变线程池状态时，首先需要使用mainLock获取锁，获取不到则阻塞等待。
    * */
    private final ReentrantLock mainLock = new ReentrantLock();

其详细流程为：
①创建线程对象
②使用ReentrantLock加锁
③检查线程池状态是否合格
④如果线程池状态OK则将线程放入队列，并将标记是否入队成功的属性workerAdded设为true。
⑤如果线程入队成功，则使用线程的start()方法启动线程。
⑥如果线程入队失败，则可能有两种原因，一是线程池状态发生改变，二是线程已经启动过了。只要线程入队失败，就要使用addWorkerFailed(Worker w)方法进行回滚。addWorkerFailed(Worker w)方法会将线程从队列中移除，并且把线程数量减1。

再次检查线程状态

在上面的流程中我们可以看到，ThreadPoolExecutor在创建线程的全部过程中，使用悲观锁锁住的部分仅仅只有再次检查线程池状态和线程入队列这两个步骤的几行代码，其他全部使用乐观锁来完成。刻意将线程创建和线程启动两个步骤细分开来，最大限度减小悲观锁的加锁区域。而且线程池状态变更比线程数量变更的频率低很多，只在检查线程池状态时加悲观锁也最大限度减少了锁竞争的发生频率。

对应的代码块为：

//走到这里，说明线程池状态和线程数量都允许创建新线程
        //新线程是否已经开始运行
        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;
                //加锁，在新线程加入workers队列时不允许有其他线程改变线程池状态
                mainLock.lock();
                try {
                    //再次检查线程池状态，是否运行创建新的worker
                    int rs = runStateOf(ctl.get());
                    if (rs < SHUTDOWN ||
                            (rs == SHUTDOWN && firstTask == null)) {
                        //新线程肯定是还没有开始运行的，这里可能是程序员自定义ThreadFactory
                        //实现类时在内部就start了
                        if (t.isAlive())
                            throw new IllegalThreadStateException();
                        //worker加入线程队列
                        workers.add(w);
                        //调整largestPoolSize值
                        int s = workers.size();
                        if (s > largestPoolSize)
                            largestPoolSize = s;
                        workerAdded = true;
                    }
                } finally {
                    mainLock.unlock();
                }
                //加入集合成功，才启动新线程
                if (workerAdded) {
                    t.start();
                    workerStarted = true;
                }
            }
        } finally {
            //检测线程池状态发生变化后，那新线程不能被启动，则需要把已创建的Worker从集合中移除，
            // 并且把ctl的线程数量部分再减1,其实就是addWorkerFailed
            if (! workerStarted)
                addWorkerFailed(w);
        }

线程执行任务：不可重入锁防止线程被中断

线程池使用Worker来封装线程，在Worker的源码中，其继承了同步器的模板AQS并实现了一个不可重入锁。在此，先简单介绍一下AQS的实现原理：

1、AQS内部定义了一个state变量作为锁计数器，当state的值为0时，表示当前没有线程持有锁；当state的值为1时，表示有一个线程持有了锁；当state的值大于1时，表示线程重入了该锁。
2、AQS会使用一个属性来记录当前是哪个线程持有了锁。
3、AQS内部维护了一个队列，常称之为同步队列，让所有需要排队等待锁的线程都加入队列中并且进入阻塞状态。然后当持有锁的线程释放锁以后，唤醒位于队列头部的线程。
4、为了支持线程可以在某个特定的条件下等待或者唤醒，即实现Condition接口的功能，AQS内部还需要有另外一个队列，常称之为条件队列。Condition实例让一个线程进入等待状态时，该线程会被放入到条件队列。直到调用signal或signalAll方法后，再将线程转移到外部类AQS的等待队列中，线程需要获取到AQS等待队列的锁，才可以继续恢复执行后续的用户代码。
第4点在线程池中没有涉及到。

Worker继承了AQS，并且获取锁的tryAcquire(int unused)方法设计为：使用 CAS 修改 AQS 中的锁计数器state，期望值为0（0的时候表示锁未被任何线程获取过），即只有在state为0时才能修改成功获得锁。这样就成了不可重入的独占锁。释放锁时直接将锁计数器置为0。

下面摘自Worker类的源码：

//尝试去占用当前 worker 的独占锁
        //只有锁状态原先为0并且将其改成1才能成功获取锁，这样就成了不可重入的独占锁
        protected boolean tryAcquire(int unused) {
            // 使用 CAS 修改 AQS 中的state，期望值为0（0的时候表示未被占用），
            //修改成功表示当前线程获取锁成功，那么设置 ExclusiveOwnerThread 为当前线程
            //ExclusiveOwnerThread表示当前持有锁的线程
            if (compareAndSetState(0, 1)) {
                //设置持有锁的线程为当前线程
                setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }

        // 尝试释放当前 worker 的独占锁
        protected boolean tryRelease(int unused) {
            //设置持有锁的线程为null
            setExclusiveOwnerThread(null);
            //锁计数器的值改为0
            setState(0);
            return true;
        }

在有某线程调用interruptIdleWorkers(boolean onlyOne)中断线程时，会先获取worker的独占锁才能中断worker的线程。但是正在执行任务的线程独占锁已经被占用了，而且因为该独占锁是不可重入的，所以任何线程都不能再次获取，则无法将正在执行任务的线程中断。
相关代码为：

/*
    * 此函数尝试中断空闲的Worker线程。Worker线程在执行task的前提是持有自己的Worker锁，
    * 相反，空闲的线程是没有持有自己的Worker锁的，所以当前线程执行w.tryLock()是能返回true的。
    * 参数onlyOne为true时，只中断一个空闲的Worker线程，反正中断所有空闲线程。*/
    private void interruptIdleWorkers(boolean onlyOne) {
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            for (Worker w : workers) {
                Thread t = w.thread;
                //没有被中断过的线程，并且这个线程并没有在运行task（运行task时会持有worker锁）
                //注意，w.tryLock()一定得放到右边，不然可能获得锁后不释放锁
                if (!t.isInterrupted() && w.tryLock()) {
                    try {
                        t.interrupt();
                    } catch (SecurityException ignore) {
                    } finally {
                        w.unlock();
                    }
                }
                //onlyOne为true则只中断一个空闲线程即可
                if (onlyOne)
                    break;
            }
        } finally {
            mainLock.unlock();
        }
    }

线程数量的增与减：使用CAS保证准确

这个没啥好说的了，就是使用CAS机制来防止并发问题呗。

    //线程数量增1
    private boolean compareAndIncrementWorkerCount(int expect) {
        return ctl.compareAndSet(expect, expect + 1);
    }
    线程数量减1
    private boolean compareAndDecrementWorkerCount(int expect) {
        return ctl.compareAndSet(expect, expect - 1);
    }