轻量级动态线程池才是“王道”？（二）

二、Hippo4j Core
所谓“一图胜千言”，小编画了一张图，来描述它的交互行为以及所支持功能。

 
只要你们项目中有配置中心，引用 hippo4j-core-spring-boot-starter 后，就可以使用以上功能啦。

1. 动态线程池参数更新
客户端项目启动时向配置中心请求动态线程池配置，获取配置后创建 DynamicThreadPool 线程池。

并向配置中心发起监听事件，当配置中心中配置发生变更时，监听事件实时修改项目中的线程池参数。

如在配置中心变更了动态线程池配置，会在日志中打印变更信息：

[MESSAGE-CONSUME] Changed thread pool. 
    coreSize :: [1 => 10]
    maxSize :: [1 => 20]
    queueType :: [ResizableCapacityLinkedBlockIngQueue => ResizableCapacityLinkedBlockIngQueue]
    capacity :: [1024 => 2048]
    keepAliveTime :: [1000 => 1000]
    executeTimeOut :: [600 => 600]
    rejectedType :: [DiscardOldestPolicy => DiscardOldestPolicy]
    allowCoreThreadTimeOut :: [false => false]

同时，通过消息推送通知相关负责人。目前通知平台已支持钉钉、企业微信以及飞书三种常用办公软件，以企业微信群聊机器人举例：

 
2. Web 线程池参数更新
SpringBoot 内置三种 Web 容器：Tomcat、Jetty、Undertow。

Hippo4j Core 已支持容器线程池的核心参数变更：corePoolSize、maximumPoolSize、keepAliveTime。

为什么要加 Web 线程池的动态更新？两个原因：

• 压测应用时，需要针对不同的压测流量来调整 Web 容器线程池的线程数。正常流程，调整后需要重新发布项目，无疑是比较费时费力；
• 当 SpringBoot Java 应用响应时间变慢，并且服务器整体负载不高时，我们可以通过修改 Web 容器线程池来提高并行处理能力，以此提高响应时间。
  当然，正常来说，线上的容器线程池配置是通过压测后得出的最优值。所以，这个功能在线上应该谨慎使用，或者说尽量不在线上使用。

3. 动态线程池报警策略
为了让线程池运行出现问题，及时通知到相关负责人，Hippo4j 针对线程池做了四种定制化报警策略：

• 活跃度报警：假设设置线程池活跃度报警阈值为 80%，最大线程数 10。当线程数达到 8 发起报警；
• 阻塞队列容量报警：假设设置容量报警阈值为 80%，阻塞队列容量 100。当容量达到 80 发起报警；
• 拒绝任务报警：当线程池无法执行任务，开始执行拒绝策略时报警；
• 执行时间报警：假设线程池超时时间设置 1000ms，任务执行时间超过 1000ms 发起报警。
  问题比较多的小伙伴就问了，如果线程池 频繁拒绝任务或者执行时间频繁超时，那岂不是要被信息轰炸？

不会的。报警策略做了优化，当设置报警间隔时间内，线程池 + 报警类型 两个维度仅会发出一条通知报警消息。

举个例子，有一个线程池 ID：message-consum 的线程池，设置了报警间隔为 5 分钟。

也就是说，活跃度、阻塞队列容量、拒绝任务、执行时间几个报警纬度，message-consum 线程池在 5分钟内最多每个类型发送一条报警通知。

目前已支持了钉钉、企业微信以及飞书的群机器人报警。企业微信机器人示例如下：

 
上图中的链路信息只会在超时报警时存在，这样可以通过链路信息，更方便定位到线程池任务执行缓慢的原因。

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