今天,说一说线程池 “动态更新”(一)

发布于 2022-6-23 17:05
浏览
0收藏

 

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

 

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

已于2022-6-23 17:05:21修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐