背景
使用线程池 ThreadPoolExecutor 过程中你是否有以下痛点呢？
1.代码中创建了一个 ThreadPoolExecutor，但是不知道那几个核心参数设置多少比较合适
2.凭经验设置参数值，上线后发现需要调整，改代码重启服务，非常麻烦
3.线程池相对开发人员来说是个黑盒，运行情况不能及时感知到，直到出现问题
如果你有以上痛点，动态可监控线程池（DynamicTp）或许能帮助到你。
如果看过 ThreadPoolExecutor 的源码，大概可以知道它对核心参数基本都有提供 set / get 方法以及一些扩展方法，可以在运行时动态修改、获取相应的值。
现在大多数的互联网项目其实都会微服务化部署，有一套自己的服务治理体系，微服务组件中的分布式配置中心扮演的就是动态修改配置， 实时生效的角色。那么我们是否可以结合配置中心来做运行时线程池参数的动态调整呢？答案是肯定的，而且配置中心相对都是高可用的， 使用它也不用过于担心配置推送出现问题这类事儿，而且也能减少研发动态线程池组件的难度和工作量。
综上，可以总结出以下的背景
广泛性：在 Java 开发中，想要提高系统性能，线程池已经是一个 90%以上的人都会选择使用的基础工具
不确定性：项目中可能会创建很多线程池，既有 IO 密集型的，也有 CPU 密集型的，但线程池的参数并不好确定；需要有套机制在运行过程中动态去调整参数
无感知性，线程池运行过程中的各项指标一般感知不到；需要有套监控报警机制在事前、事中就能让开发人员感知到线程池的运行状况，及时处理
高可用性，配置变更需要及时推送到客户端；需要有高可用的配置管理推送服务，配置中心是现在大多数互联网系统都会使用的组件，与之结合可以大幅度减少开发量及接入难度
简介
基于以上背景分析，我们对线程池 ThreadPoolExecutor 做一些扩展增强，主要实现以下目标
1.实现对运行中线程池参数的动态修改，实时生效
2.实时监控线程池的运行状态，触发设置的报警策略时报警，报警信息推送办公平台
3.定时采集线程池指标数据，配合像 grafana 这种可视化监控平台做大盘监控
经过多个版本的迭代，目前最新版本 v1.0.9 具有以下特性 ✅
代码零侵入 ：所有配置都放在配置中心，对业务代码零侵入
轻量简单 ：基于 SpringBoot 实现，引入 starter，接入只需简单 4 步就可完成，顺利 3 分钟搞定
高可扩展 ：框架核心功能都提供 SPI 接口供用户自定义个性化实现（配置中心、配置文件解析、通知告警、监控数据采集、任务包装等等）
线上大规模应用 ：参考美团线程池实践，美团内部已经有该理论成熟的应用经验
多平台通知报警 ：提供多种报警维度（配置变更通知、活性报警、容量阈值报警、拒绝触发报警、任务执行或等待超时报警），已支持企业微信、钉钉、飞书、邮件报警，同时提供 SPI 接口可自定义扩展实现
监控 ：定时采集线程池指标数据，支持通过 MicroMeter、JsonLog 日志输出、Endpoint 三种方式，可通过 SPI 接口自定义扩展实现
任务增强 ：提供任务包装功能，实现 TaskWrapper 接口即可，如 MdcTaskWrapper、TtlTaskWrapper、SwTraceTaskWrapper，可以支持线程池上下文信息传递
兼容性 ：JUC 普通线程池和 Spring 中的 ThreadPoolTaskExecutor 也可以被框架监控，@Bean 定义时加 @DynamicTp 注解即可
可靠性 ：框架提供的线程池实现 Spring 生命周期方法，可以在 Spring 容器关闭前尽可能多的处理队列中的任务
多模式 ：参考 Tomcat 线程池提供了 IO 密集型场景使用的 EagerDtpExecutor 线程池
支持多配置中心 ：基于主流配置中心实现线程池参数动态调整，实时生效，已支持 Nacos、Apollo、Zookeeper、Consul、Etcd，同时也提供 SPI 接口可自定义扩展实现
中间件线程池管理 ：集成管理常用第三方组件的线程池，已集成Tomcat、Jetty、Undertow、Dubbo、RocketMq、Hystrix、Grpc 等组件的线程池管理（调参、监控报警）
架构设计
框架功能大体可以分为以下几个模块
1.配置变更监听模块 2.服务内部线程池管理模块 3.三方组件线程池管理模块 4.监控模块 5.通知告警模块
代码结构
1.adapter 模块：主要是适配一些第三方组件的线程池管理，目前已经实现的有 SpringBoot 内置的三大 web 容器（Tomcat、Jetty、Undertow）、Dubbo、RocketMq、Hystrix、Grpc 的线程池管理， 后续会接入其他常用组件的线程池管理。 2.common 模块：主要是一些各个模板都会用到的类，解耦依赖，复用代码，大家日常开发中可能也经常会这样做。 3.core 模块：该框架的核心代码都在这个模块里，包括动态调整参数，监控报警，以及串联整个项目流程都在此。 4.example 模块：提供一个简单使用示例，方便使用者参照 5.extension 模块：放一些扩展功能实现，比如基于 redis 的流控扩展、邮件发送扩展、skywalking 上下文传递扩展等 6.logging 模块：用于配置框架内部日志的输出，目前主要用于输出线程池监控指标数据到指定文件 7.starter模块：提供独立功能模块的依赖封装、自动配置等相关。
配置变更监听模块
1.监听特定配置中心的指定配置文件（已实现 Nacos、Apollo、Zookeeper、Consul、Etcd），可通过内部提供的SPI接口扩展其他实现
2.解析配置文件内容，内置实现 yml、properties、json 配置文件的解析，可通过内部提供的 SPI 接口扩展其他实现
3.通知线程池管理模块实现参数的刷新
服务内部线程池管理模块
1.服务启动时从配置中心拉取配置，生成线程池实例注册到内部线程池注册中心以及 Spring 容器中
2.接受配置监听模块的刷新事件，实现线程池参数的刷新
3.代码中通过依赖注入（推荐）或者 DtpRegistry.getDtpExecutor() 方法根据线程池名称来获取线程池实例
三方组件线程池管理
1.服务启动获取第三方中间件的线程池，被框架管理起来
2.接受参数刷新、指标收集、通知报警事件，进行相应的处理
监控模块
实现监控指标采集以及输出，默认提供以下三种方式，也可通过内部提供的 SPI 接口扩展其他实现
1.默认实现 JsonLog 输出到磁盘，可以自己采集解析日志，存储展示
2.MicroMeter采集，引入 MicroMeter 相关依赖，暴露相关端点，采集指标数据，结合 Grafana 做监控大盘
3.暴雷自定义 Endpoint 端点（dynamic-tp），可通过 http 方式实时访问
通知告警模块
对接办公平台，实现通知告警功能，已支持钉钉、企微、飞书、邮件，可通过内部提供的 SPI 接口扩展其他实现，通知告警类型如下
1.线程池主要参数变更通知
2.阻塞队列容量达到设置的告警阈值
3.线程池活性达到设置的告警阈值
4.触发拒绝策略告警，格式：A/B，A：该报警项前后两次报警区间累加数量，B：该报警项累计总数
5.任务执行超时告警，格式：A/B，A：该报警项前后两次报警区间累加数量，B：该报警项累计总数
6.任务等待超时告警，格式：A/B，A：该报警项前后两次报警区间累加数量，B：该报警项累计总数
项目地址
gitee地址：https://gitee.com/dromara/dynamic-tp github地址：https://github.com/dromara/dynamic-tp
