一、前言

在一次新功能上线过程中,出现线程池提交任务抛出 RejectedExecutionException 异常,即任务提交执行了拒绝策略的操作。查看业务情况和线程池配置,发现并行执行的任务数是小于线程池最大线程数的,为此展开了一次线程池问题排查历程。

二、业务情景

2.1. 任务描述

每次执行一组任务,一组任务最多有 15 个,多线程执行,每个线程处理一个任务;每次执行完一组任务后,再执行下一组,不存在上一组的任务和下一组一起执行的情况。

2.2. 任务提交流程

image.png

2.3. 线程池配置

  1. <bean id="executor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
  2. <property name="corePoolSize" value="14"/>
  3. <property name="maxPoolSize" value="30"/>
  4. <property name="queueCapacity" value="1"/>
  5. </bean>

三、出现问题

执行过程中出现 RejectedExecutionException 异常,由于是采用的是默认拒绝策略 AbortPolicy,因此,可以明确知道任务是提交到线程池后,线程池资源已满,导致任务被拒绝。

四、问题排查

4.1. 检查线程池配置

任务最多 15 个一组,核心线程有 14 个,阻塞队列是 1,最大线程 30,理论上 14 个核心线程+1 个阻塞队列即可完成一组任务,连非核心线程都无需使用,为什么会出现线程被占满的情况?

4.2. 检查业务代码

检查是否存在线程池被多处使用,或者有多批任务被同时执行的情况,并没有发现错误;

4.3. 线下重现

  • 配置线程池

    1. <bean id="executor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
    2. <property name="corePoolSize" value="14"/>
    3. <property name="maxPoolSize" value="30"/>
    4. <property name="queueCapacity" value="1"/>
    5. </bean>
  • 建立 demo 代码

    1. @RunWith(SpringRunner.class)
    2. @SpringBootTest
    3. public class SpringBootStartApplicationTests {
    4. @Resource
    5. private ThreadPoolTaskExecutor executor;
    6. @Test
    7. public void contextLoads() throws Exception {
    8. // 一共 10 批任务
    9. for(int i = 0; i < 10; i++) {
    10. // 每次执行一批任务
    11. doOnceTasks();
    12. System.out.println("---------------------------------------" + i);
    13. }
    14. }
    15. /**
    16. * 每次完成 15 个任务后,再进行下一次任务
    17. */
    18. private void doOnceTasks(){
    19. List<Future> futureList = Lists.newArrayListWithCapacity(15);
    20. for(int i = 0; i < 15; ++i){
    21. Future future = executor.submit(()->{
    22. // 随机睡 0-5 秒
    23. int sec = new Double(Math.random() * 5).intValue();
    24. LockSupport.parkNanos(sec * 1000 * 1000 * 1000);
    25. System.out.println(Thread.currentThread().getName() + " end");
    26. });
    27. futureList.add(future);
    28. }
    29. // 等待所有任务执行结束
    30. for(Future future : futureList){
    31. try {
    32. future.get();
    33. } catch (Exception e) {
    34. e.printStackTrace();
    35. }
    36. }
    37. }
    38. }
  • 异常重现

image.png

五、线程池源码阅读

  • 当工作线程数 < corePoolSize 时,新创建一个新线程执行新提交任务,即使此时线程池中存在空闲线程;
  • 当工作线程数 == corePoolSize 时,新提交任务将被放入 workQueue 中;
  • 当 workQueue 已满,且工作线程数 < maximumPoolSize 时,新提交任务会创建新的非核心线程执行任务;
  • 当 workQueue 已满,且 工作线程数==maximumPoolSize 时,新提交任务由 RejectedExecutionHandler 处理;


image.png

5.2. execute 线程池提交任务源码

  1. class ThreadPoolExecutor{
  2. public void execute(Runnable command) {
  3. // 提交任务不能为 null
  4. if (command == null)
  5. throw new NullPointerException();
  6. // 获取控制位 ctl 的值
  7. int c = ctl.get();
  8. // work 线程数 < 核心线程数
  9. if (workerCountOf(c) < corePoolSize) {
  10. // 直接创建核心线程,执行任务
  11. if (addWorker(command, true))
  12. return;
  13. /*
  14. 因为没有使用锁,可能会出现并发创建核心线程;
  15. 走到这里,说明核心线程已经创建满了,此时,重新获取控制位 ctl 的值
  16. */
  17. c = ctl.get();
  18. }
  19. // 如果线程池还是 RUNNING 状态,并且任务成功提交到阻塞队列中
  20. if (isRunning(c) && workQueue.offer(command)) {
  21. int recheck = ctl.get();
  22. // double-check,再检查一次线程池状态
  23. // 如果线程池变成非 RUNNING 状态,则回滚刚才新加的任务
  24. if (! isRunning(recheck) && remove(command))
  25. // 从阻塞队列中移除任务成功,使用拒绝策略执行任务
  26. reject(command);
  27. // 如果工作线程数==0,则添加一个线程
  28. // 主要是兼容核心线程数==0 的情况
  29. else if (workerCountOf(recheck) == 0)
  30. addWorker(null, false);
  31. }
  32. /*
  33. 到达这里,则说明核心线程数已满,且阻塞队列已满
  34. 尝试创建非核心线程执行任务
  35. */
  36. else if (!addWorker(command, false))
  37. // 非核心线程创建失败了,说明是线程数以达到 maximumPoolSize,此时执行拒绝策略
  38. reject(command);
  39. }
  40. }

5.3. addWorker 添加 worker 线程

  1. class ThreadPoolExecutor{
  2. /**
  3. * 添加一个 worker 线程
  4. * @param firstTask 第一个要执行的 task
  5. * @param core 是否是核心线程
  6. * @return 创建成功还是失败
  7. */
  8. private boolean addWorker(Runnable firstTask, boolean core) {
  9. // 定义了一个 retry 标签
  10. retry:
  11. for (;;) {
  12. // 获取控制位
  13. int c = ctl.get();
  14. // 获取运行状态
  15. int rs = runStateOf(c);
  16. /**
  17. * rs >= SHUTDOWN:即非 RUNNING 状态,只有 RUNNING < SHUTDOWN
  18. * ! (rs == SHUTDOWN && firstTask == null && ! workQueue.isEmpty())
  19. * 等价于 非 SHUTDOWN 态 || firstTask != null || workQueue.isEmpty()
  20. * 非 SHUTDOWN 态 == true:SHUTDOWN 态之后的状态,都不允许再添加 worker 线程了,直接返回 false;
  21. * 非 SHUTDOWN 态 == false || (firstTask != null) == true:SHUTDOWN 状态下,不允许再添加任务了,返回 false;
  22. * 非 SHUTDOWN 态 == false || (firstTask != null) == false || workQueue.isEmpty() == true:SHUTDOWN 状态,没提交新任务,阻塞队列又是空的,没必要再添加线程了
  23. */
  24. if (rs >= SHUTDOWN &&
  25. ! (rs == SHUTDOWN &&
  26. firstTask == null &&
  27. ! workQueue.isEmpty()))
  28. return false;
  29. // CAS 创建 worker 线程
  30. for (;;) {
  31. // 获取线程数
  32. int wc = workerCountOf(c);
  33. /*
  34. 当前线程数大于最大值
  35. 当前创建的是核心线程,但线程数量已经>=核心线程数
  36. 当前创建非核心线程,但线程数量已经>=maximumPoolSize
  37. */
  38. if (wc >= CAPACITY ||
  39. wc >= (core ? corePoolSize : maximumPoolSize))
  40. // 不创建,直接返回 false
  41. return false;
  42. // cas 修改 ctl 中的线程数,线程数+1
  43. if (compareAndIncrementWorkerCount(c))
  44. // cas 修改成功,break goto 结束循环(不会再进入标签下的循环)
  45. break retry;
  46. // 达到这里,说明 cas 增加线程数 1 失败了,此时进行尝试
  47. c = ctl.get();
  48. // 先判断一下线程池状态有没有改变,如果改变了,则 continue goto(会再进入标签下的循环)
  49. // 跳转到最外层的循环,重新检测线程池的状态值
  50. if (runStateOf(c) != rs)
  51. continue retry;
  52. }
  53. }
  54. boolean workerStarted = false;
  55. boolean workerAdded = false;
  56. Worker w = null;
  57. try {
  58. // 创建 worker 对象
  59. w = new Worker(firstTask);
  60. // 获取 worker 的线程
  61. final Thread t = w.thread;
  62. if (t != null) {
  63. // 加锁
  64. final ReentrantLock mainLock = this.mainLock;
  65. mainLock.lock();
  66. try {
  67. // 获取线程池状态
  68. int rs = runStateOf(ctl.get());
  69. /*
  70. 线程池是 RUNNING 状态
  71. SHUTDOWN 态 且 firstTask == null(这种情况是需要创建线程,消费队列中剩余的任务)
  72. */
  73. if (rs < SHUTDOWN ||
  74. (rs == SHUTDOWN && firstTask == null)) {
  75. // 线程是活动状态,则不合法,因为线程是刚创建的,应该是 NEW 状态
  76. if (t.isAlive())
  77. throw new IllegalThreadStateException();
  78. // 将 worker 添加到 list 中
  79. workers.add(w);
  80. // largestPoolSize 记录该线程池使用过程中,达到最大的线程数
  81. int s = workers.size();
  82. if (s > largestPoolSize)
  83. largestPoolSize = s;
  84. // worker 添加成功,workerAdded 置为 true
  85. workerAdded = true;
  86. }
  87. } finally {
  88. mainLock.unlock();
  89. }
  90. // worker 添加成功,此时就可以启动线程
  91. if (workerAdded) {
  92. t.start();
  93. // 启动线程成功,workerStarted 置为 true
  94. workerStarted = true;
  95. }
  96. }
  97. } finally {
  98. // 如果 worker 启动失败,则移除它
  99. if (! workerStarted)
  100. // workers 移除新加的 worker,并在 ctl 中将 work 线程数量-1
  101. addWorkerFailed(w);
  102. }
  103. return workerStarted;
  104. }
  105. }

六、问题定位

6.1. 定位执行拒绝策略入口

执行拒绝策略的位置只有这两个地方,在这两个地方打上断点,执行 demo,结果发现拒绝策略是在第二处执行的;
image.png

6.2. 定位执行拒绝策略原因

进入 addWorker 方法,只有这两个地方返回 false,创建线程失败,打断点,执行 demo,发现是在第二处返回 false 的;
image.png

七、问题确认

确实是创建的 worker 线程已经达到最大线程数,无法再创建,然后执行拒绝策略的,为什么会被创建到最大呢,每组任务最大只有 15 个,为什么会用到非核心线程?

八、定位原因

8.1. 分析 execute 方法

在添加非核心线程前,先尝试将任务放到阻塞队列中,如果阻塞队列已满,则尝试添加非核心线程,也就是说,创建非核心线程时:workQueue.offer(command) == false,即阻塞队列已满;
image.png

8.2. 猜测原因

因为我们阻塞队列只有 1,会不会提交任务的速度比线程从阻塞队列取任务的速度快,进而导致创建非核心线程执行任务,最终的结果就是:在多批任务之后,再无非核心线程可创建,导致执行拒绝策略。
image.png

8.3. 原因验证

8.3.1 阻塞队列选择

查看 Spring 的 ThreadPoolTaskExecutor 源码,发现如果阻塞队列数量>0,则使用 LinkedBlockingQueue,否则使用 SynchronousQueue。
image.png

8.3.2 LinkedBlockingQueue

  • 查看 LinkedBlockingQueue#take 方法,如果队列已空,则所有取元素的线程会阻塞在一个 Lock 的 notEmpty 等待条件上,等有元素入队时,只会调用 signal 方法唤醒一个线程取元素,而不是所有线程。

    1. class LinkedBlockingQueue{
    2. private void signalNotEmpty() {
    3. final ReentrantLock takeLock = this.takeLock;
    4. // 加锁
    5. takeLock.lock();
    6. try {
    7. // 唤醒一个 take 线程
    8. notEmpty.signal();
    9. } finally {
    10. takeLock.unlock();
    11. }
    12. }
    13. }
  • 因为一个线程从唤醒到执行是有一段时间间隔的,阻塞被唤醒后,还要等待获取 cpu 时间片,而主线程一直在发布任务,此时就会造成队列中的元素来不及消费,只能创建非核心线程消费的现象。

    九、解决方式

    9.1. 使用 SynchronousQueue

    使用 SynchronousQueue,即阻塞队列大小设置为 0,原因在于:SynchronousQueue 和 LinkedBlockingQueue 维度不一致,SynchronousQueue 是根据是否有等待线程而决定是否入队成功,而 LinkedBlockingQueue 是根据缓冲区,而不管是否已经有等待线程。

  • SynchronousQueue

image.png

  • LinkedBlockingQueue

image.png

9.2. 根据业务情况配置阻塞队列

对于我们的业务情况,因为任务最多只有 15 个,将阻塞队列大小设置为 15,这样就保证了不会出现任务被拒绝。