今天，说一说线程池 “动态更新”

线程池（Thread Pool）是一种基于 池化思想管理线程的工具。使用线程池可以 减少创建销毁线程的开销，避免线程过多导致系统资源耗尽

目前线程池被广泛应用于业务系统，但是业界内对线程池 初始化参数并没有很好的标准。线上环境的线程池因为业务特殊性遇到一些痛点，进而引发了小编对于线程池使用的一些思考

线上配置不能合理评估

最大的痛点就是无法正确评估线程池关键参数的配置。比如核心线程数、最大线程数、阻塞队列大小等，一旦上线参数就无法更改

设想一下，当你兴致勃勃的对业务使用了线程池之后，有没有考虑过这几种场景

1. 核心线程过小，阻塞队列过小，最大线程过小，导致接口频繁抛出拒绝策略异常
2. 核心线程过小，阻塞队列过小，最大线程过大，导致线程调度开销增大，处理速度下降。如果遇到周期性突发流量，更是如此
3. 核心线程过小，阻塞队列过大，导致任务堆积，接口响应或者程序执行时间拉长
4. 核心线程过大，导致线程池内空闲线程过多，过多的占用系统资源，造成资源浪费

上面的某些场景，受其它参数的影响，并不是绝对成立

曾经这么考虑过，提前计算好线程池的各项参数不就 OK 了么，要什么动态？

这里说一下，大多数的业务场景下，线程池参数最好的情况是大差不差。什么意思呢，就是当业务运行中时，线程池有少量的资源浪费或者触发少量的拒绝任务

但是，有些业务的波动并不是可以预测的。比如说有一家开饭店的老板，周一到周四客人并不多，所以平常也没备那么多的菜，凑巧来了一个旅游团来吃饭，饭店存量也就捉襟见肘了，而这种突发情况并不可预估

如果业务系统遇到上述情况，可能需要根据突来的流量重新预估线程池的参数，将系统重新进行发布并查看当前线程池的参数是否合理，如果不合理极有可能还要再来一遍流程

而动态线程池要做的就是将 参数的修改与系统的发布进行隔离，流程图如下

没有合理的监控

上面提到出现的参数不合理场景如何发现呢，那就是 线程池运行时监控

如果可以知道一部分线程池运行时指标，可以极大程度上的预防上述问题，这里举一些例子

1. 监控业务线程池的 当前负载以及峰值负载
2. 监控线程池在不同时间段 核心线程、最大线程、活跃线程数量指标
3. 监控线程 池阻塞队列相关指标，判断是否有任务积压的风险
4. 监控线程任务在 运行时抛出的异常数量，诊断投递的任务是否“健康”
5. 监控线程池执行 拒绝策略执行的次数，确定线程池参数是否合理

如果监控搭配上合理的报警信息，可以极大程度上避免开发对于线上业务的后知后觉，有效预防一些问题以及提高业务 BUG 的修复速度

上述关于线程池动态参数、监控以及预警等思考，源自于美团技术博客 《Java 线程池实现原理及其在美团业务中的实践》[1]

如何动态更新参数

动态设置线程池参数涉及到两个问题，都有哪些参数可以动态更新？使用什么方式动态更新？

这里先列举下原声线程池 API 支持修改的参数集合，然后梳理看看支持修改后有什么好处

CorePoolSize（核心线程数量）

线程池中空闲时存在最小的线程数量。可以通过 #setCorePoolSize 修改线程池核心线程数量，流程图如下

相对于其它几个动态参数，核心线程数的动态设置流程还算复杂一些

1. 判断设置的 new corePoolSize 必须大于 0，否则抛出异常
2. 直接替换线程池的 corePoolSize 为 new corePoolSize
3. 判断线程池的工作线程是否大于 new corePoolSize，条件如果成立则执行中断多余空闲的线程
4. 如果上述条件不成立，判断 corePoolSize 是否小于 new corePoolSize，如果小于说明需要创建新的核心线程

关于第四步，有一个小知识点，线程池作者为了保证线程资源不浪费而做出的优化

执行第四步时通过注释得知，并不知道需要创建多少线程，而为了保证线程资源不会被浪费，这里会依据 workQueue#size 和 delata 来计算出需要创建的线程数量 k

Math#min 会返回两个值中小的那个，小编想到了三种情况，我们这里来假设下

1. 假设 workQueue#size == 0，那么 k 也等于零，证明并没有阻塞住的任务需要执行，k-- > 0 表达式并不成立，就不会执行 #addWorker
2. 假设 workQueue#size > 0 && < delta，此时任务队列里有待执行任务。k-- > 0 表达式成立，一般情况会创建 workQueue#size 个新核心线程，二般情况下是线程池里其它线程把 workQueue 的任务清了，就会跳出创建流程
3. 假设 workQueue#size > 0 && > delta，这种情况最多会创建 delata 个新核心线程

这里也给我们一个启发，写代码不能只顾着自扫门前雪，而是要从全局的角度去思考代码有没有可以提升的空间

小编问了下自己，核心线程在没任务时是不会被回收的，如果核心线程数设置的太大，过去了峰值期岂不是属于资源浪费，难道还要自己再把数量调整回来么

我们可以在创建线程池时通过设置一个参数控制。allowsCoreThreadTimeOut 默认为 False，即核心线程即使在空闲时也保持活动状态。如果为 True，核心线程使用 keepAliveTime 来超时等待工作

核心线程动态的坑

有一个很重要的点需要注意，核心线程数设置时可能失效。比如说，最大线程数为 5，当前线程池内活跃线程数为 5，此时设置核心线程数为 10 的话，一定是不生效的，Why？

先假设线程池的运行时状态如下，核心线程为 3，最大线程是 5，线程池内活跃线程为 5，此时调用 #setCorePoolSize 动态设置核心线程数为 10

执行完上述操作之后，调用 #execute 向线程池发起任务执行，内部处理逻辑如下

1. 判断当前线程池核心数为 10，当前工作线程为 5，那么会 发起 #addWorker 添加线程
2. #addWorker 会对 工作线程数量 + 1，此时真正意义上并不算此 Worker 添加到线程池
3. 接下来会创建线程的包装类 Worker 并执行 Start，因为 Worker 本身持有线程对象，Start 也是操作线程去执行任务
4. 获取任务 #getTask 有一步操作是动态修改核心线程数不生效的原因，那就是在真正获取队列中任务执行时会先 判断当前的工作线程数量是否大于最大线程
5. 因为上面对工作线程有 +1 的操作，所以池内工作线程数是 6，条件判断表达式成立，接下来会对 工作线程数量执行 -1 操作，并销毁此 Worker

这里贴一下线程池获取队列任务 #getTask 的代码片段，大家粗略看一下

既然已经知道问题出在哪里，应该如何去解决动态设置失效呢

其实办法很简单，那就是在设置核心线程的时候，同时设置最大线程数就可以。只要工作线程不大于最大线程数，那么动态设置就是有效的

本小节参考自 如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答[2]

MaximumPoolSize（最大线程数）

表示线程池中可以创建的最大线程数。通过 #setMaximumPoolSize 重新设置最大线程数，修改逻辑如下

线程池中设置最大线程数的源码比较简单，并不包含复杂的逻辑，流程如下

1. 判断 new maximumPoolSize 参数是否正确，不满足条件则抛出异常终止流程
2. 设置 new maximumPoolSize 替换线程池最大线程数
3. 如果线程池工作线程大于 new maximumPoolSize，则对多余 Worker 发起中断流程

ThreadFactory（线程工厂）

线程工厂的功能是为线程池创建线程，线程创建时可以设置自定义线程 名称前缀（重要）、设置是否 daemon 线程、线程 priority 优先级以及线程未捕获异常的处理方式

虽然线程工厂可以在运行后重新设置参数，但是并不建议这么做。因为已经运行的线程不会因为被销毁，如果之前运行的线程不被销毁，一个线程池中极有可能出现两种不同语义的线程

示例代码中创建了一个线程池，并指定了线程工厂前缀名称 before。对线程池运行任务使其内部拥有 before 工厂创建线程

之后新创建一个 after 线程工厂，进行替换线程池内部工厂，并运行任务创建最大线程数，我们可以查看下日志

不出所料两个线程工厂创建的线程各自为战，并且如果没有特殊操作，这种情况会一直持续下去 。所以综上所述，并不建议业务中对线程工厂修改，不然坑的都是自己人～

其它参数

剩余两个动态调整的参数较为简单，就不一一举例说明了，大家看下源码即可

• KeepAliveTime
• RejectedExecutionHandler

还有一个很重要的参数需要动态更新，那就是 阻塞队列的大小。可能有的小伙伴就会问了，为什么不直接替换阻塞队列呢？

其实可以实现直接替换阻塞队列，但是如果直接替换会引发出很多的问题，举个最直接的例子，原队列中的堆积任务不好处理，修改容量就能解决问题的事情，没必要复杂化。所以在做动态时，考虑的只是阻塞队列的大小而不是替换

这里以 LinkedBlockingQueue 为例，队列在源码中并没有提供修改队列大小的方法，因为代表队列大小的变量 capacity 被 final 关键字修饰

大家可以考虑下，基于这种 final 修饰的情况，应该如何去扩展阻塞队列的容量修改

动态的阻塞队列

线程池中是以 生产者消费者模式，通过一个阻塞队列来缓存任务，工作线程从阻塞队列中获取任务。工作队列的接口是阻塞队列（BlockingQueue），在队列为空时，获取元素的线程会 等待队列变为非空，当队列满时，存储元素的线程会 等待队列可用

阻塞队列动态设置队列大小，有很多种操作方式。可以按照原逻辑不变加一些扩展，也可以在特定方法上进行重写，实现方式并不固定。下面说几种可以实现动态阻塞队列功能的方案

1. 复制阻塞队列源代码实现，添加 #set 方法使 capacity 可变
2. 继承阻塞队列，并在原基础上重写核心方法
3. 继承阻塞队列，反射动态修改 capacity

如果不需要重写原阻塞队列获得额外的功能，小编更倾向于第一种，代码上会更简洁一些，并且稳定

复制阻塞队列

这一种方式简单粗暴，直接把 LinkedBlockingQueue 代码复制出来一份，改个新名字 ResizableCapacityLinkedBlockIngQueue，然后把 capacity 所修饰的 final 关键字去掉，再加上一个 #setCapacity 方法

重写核心方法

网上大多数博主使用的都是上述复制阻塞队列的方式，后来和两位大佬讨论阻塞队列的动态，然后从 GitHub 上发现了一位国外程序员的版本，通过信号量的方式控制阻塞队列的大小，《GitHub LinkedBQ 信号量实现》[3]

队列中包含阻塞 队列的大小以及自实现的信号量。每次进行调整阻塞队列大小的同时也对信号量进行增减

反射修改 Capacity

通过反射的方式同样可以达到阻塞队列动态修改的功能。在修改之前，有考虑过这种方式 会不会存在线程不安全的问题，对此使用 Jmeter 线程组和修改 capacity 交替操作，进行了几轮测试，测试的结论是 不存在线程安全问题

对于使用反射修改阻塞队列大小，小编是不推荐的。首先这种硬编码的方式并不优雅，其次并不能百分百保证能兼容后续 JDK 版本

综合考虑，虽然反射修改 capacity 可以达到理想中的效果，但是不建议这么做

总结一下

在文章中，小编总结了业界内使用线程池普遍存在的情况

1. 线程池的 参数无法执行快速动态调整
2. 没有合理的监控进而导致 失去主动权 以及 有效预防潜在问题

基于第一种动态参数调整的问题写下了动态线程池系列的第一篇文章。是的，后面会有更多的动态线程池文章，包括不限于以下几个 IDEA

1. 线程池实时监控如何实现，历史指标数据 如何汇总 Admin 展示
2. 对接不同平台的报警消息，达到 可配置、优雅的一发多收效果
3. 动态线程池可不可以 对标配置中心，对接 Server 端统一管理触发参数修改

上面这些功能，其实在美团的动态线程池里都有实现，奈何并没有开源。而自己项目中确实存在这方面的痛点，所以只有 重复造个轮子

最初，花了大概三天时间写出了一个依赖中间件的版本，并可以 完成对接平台化的动态线程池。可能是因为太简单了，觉得是不是缺了点什么。后来在一个睡不着的晚上脑洞大开，如果不依赖中间件是不是也行？

继而就有了动态线程池 DTP（Dynamic-ThreadPool）项目，并且给项目 groupId 起名 io 开头。目前而言的话，DTP 仅作为小编锻炼开发能力以及产品意识的项目，每天的代码开发时间集中在下班和周六天

DTP 项目分为两个主体，Server 和 SpringBoot Starter，Server 端作为所有客户端线程池的注册中心以及历史指标数据存储，供 Admin 调取展示，Starter 会作为 Jar 被客户端所依赖与 Server 端交互

目前 DTP 已实现 Server 端和 Client 端的 动态参数更新交互，源码实现参考借鉴了 Nacos 2.0 之前的 长轮询和事件监听机制

既然选择了不依赖中间件，那么问题也就显而易见了，线上环境的单点问题。因为一旦部署集群，数据在各节点之间无法流转广播，这一块后面可能会 参考 Eureka 做分布式的 AP 模型

代码还在持续更新，源码地址：https://github.com/acmenlt/dynamic-threadpool[4]

参考资料

[1]《Java线程池实现原理及其在美团业务中的实践》: https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html

[2]如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答: https://cloud.tencent.com/developer/article/1615007

[3]《GitHub LinkedBQ 信号量实现》: https://sourl.cn/7Uvw88

[4]点击阅读原文跳转 GitHub: https://github.com/acmenlt/dynamic-threadpool