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

线程池（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 来超时等待工作

文章转自公众号：龙台的技术笔记