线程池（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 线程工厂，进行替换线程池内部工厂，并运行任务创建最大线程数，我们可以查看下日志

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