共计 4001 个字符，预计需要花费 11 分钟才能阅读完成。
大家好，我是小马哥。
线程池是一种基于 池化思维治理线程 的工具，应用线程池能够缩小 创立销毁线程的开销 ，防止线程过多导致 系统资源耗尽 。在 高并发以及大批量 的工作解决场景，线程池的应用是必不可少的。
如果有在我的项目中理论应用线程池，置信你可能会遇到以下痛点：
- 线程池轻易定义，线程资源过多，造成服务器高负载。
- 线程池参数不易评估，随着业务的并发晋升，业务面临呈现故障的危险。
- 线程池工作执行工夫超过均匀执行周期，开发人员无奈感知。
- 线程池工作沉积，触发回绝策略，影响既有业务失常运行。
- 当业务呈现超时、熔断等问题时，因为没有监控，无奈确定是不是线程池引起。
- 原生线程池不反对运行时变量的传递，比方 MDC 上下文遇到线程池就 GG。
- 无奈执行优雅敞开，当我的项目敞开时，大量正在运行的线程池工作被抛弃。
- 线程池运行中，工作执行进行，狐疑产生死锁或执行耗时操作，然而无从下手。
基于以上诸多痛点，小马哥着手 hippo4j 的开发，致力于打造规范线程池 动静变更 和 监控 的中间件框架。
GitHub：https://github.com/opengoofy/hippo4j
Gitee：https://gitee.com/agentart/hippo4j
什么是 hippo4j
hippo4j 通过对 JDK ThreadPoolExecutor 线程池加强，以及扩大三方框架底层线程池等性能，为业务零碎进步线上运行保障能力。
小贴士：hippo4j 不止于 Java ThreadPoolExecutor 的加强，Dubbo、RabbitMQ、RocketMQ、Hystrix、Tomcat、Jetty、Undertow 等框架线程池也都有进行监控和动静变更。
什么场景适宜用 hippo4j
1. 线程池随便定义，造成服务器高负载
在零碎开发的过程中，因为波及到多人合作，难免会呈现信息不互通的状况。在同一个零碎，对于线程池来说，常见的是线程池随便定义。
- 开发者张三要记录用户操作日志，定义了
user-log-record-thread-pool； - 开发者李四要记录会员操作日志，定义了
member-log-record-thread-pool； - 开发者王五要记录权限操作日志，定义了
power-log-record-thread-pool； - ……
随着零碎一直开发，雷同或不同语义的线程池被定义的越来越多，间接导致服务器资源重大耗损。
而如果零碎中应用 hippo4j，可能在控制台查看以后利用已有线程池，是否存在雷同语义且业务可复用线程池实例，防止线程资源适度节约。
2. 线程池参数不易评估
业务中应用了线程池，十个程序员可能有九个都在犯嘀咕，这线程池的配置应该如何抉择？
我感觉犯纠结的点次要有两个，无外乎设置的数多了或者少了。
-
如果预设的线程数或阻塞队列数量少了，当业务量上来，会遇到两种状况，不论哪一种对业务来说都是不能承受的。
- 预估 200ms 执行完的工作，可能会 2s 执行完，因为工作都在排队。
- 工作满了后，开始执行回绝策略，影响失常业务。
-
如果超量设置线程池的参数，无疑会造成资源节约，同样会造成两种状况。
- 线程资源也是占用服务器资源的，开启的多了对服务器有肯定压力。
- 如果过多的创立线程，当和其它线程池一起执行时，服务器 CPU 上下文切换也是个问题。
大家都晓得，如果要批改运行中利用线程池参数，须要进行线上利用，调整胜利后再公布，而这个过程异样的繁琐，如果能在运行中动静调整线程池的参数多好。
美团技术团队基于这些痛点，推出了动静线程池的概念，催生了一批动静线程池框架，hippo4j 也是其一。
如果利用是集群部署，hippo4j 能够抉择批改线程池 某一实例 ，或者批改 集群全副实例，运行时失效，不须要再重启服务。
再比方，压测时应用 hippo4j 动静调整线程池参数，对于开发测试来说，也是个不错的抉择。
3. 线程池运行时报警策略
从线程池运行时监控的角度登程，hippo4j 内置 4 种报警策略，线程池活跃度、阻塞队列容量、回绝策略触发以及工作运行超时报警。
- 线程池活跃度：假如阈值设置 80%，线程池最大线程数 10，当线程数达到 8 发动报警。
- 阻塞队列容量：假如阈值设置 80%，阻塞队列容量 100，当容量达到 80 发动报警。
- 触发回绝策略：当线程池工作触发了回绝策略时，发动回绝策略报警。
- 工作运行超时：假如单个工作超时为 1000ms，工作执行超过该工夫发动报警。
hippo4j 反对钉钉、企业微信和飞书软件告诉，线程池工作运行超时报警示例：
4. 线程池运行时状态对开发者黑盒
线程池在服务运行过程中，对开发者来说是一个齐全的黑盒。开发者无奈得悉线程池的参数变动，比方阻塞队列数量或者实现工作数等外围参数，这对于排查问题来说并不敌对。
hippo4j 反对线程池运行时状态实时查看，并在外围参数的根底上扩大了 负载、内存以及回绝次数 等要害指标，每次查问返回线程池以后运行信息。
5. 线程池监控
hippo4j 提供了两种线程池运行时数据监控形式，别离是：
1、内置数据池数据采集 + 监控，无需依赖任何中间件，由 hippo4j 外部集成的形式运行。
2、应用三方中间件 Prometheus + Grafana 或 ElasticSearch + Grafana 采集和监控。
6. 整合 Spring ThreadPoolTaskExecutor
Spring ThreadPoolTaskExecutor 对原生线程池扩大了一部分性能，我认为比拟实用有两个，并且 hippo4j 也曾经反对。
- 当服务进行时，告诉线程池解决残余工作，并在期待指定工夫后强制进行。
- 传递线程上下文到线程池执行上下文中。
第一个是理论应用中很外围的性能，缩小了线程池抛弃工作的可能，这里重点阐明下。
咱们平时在进行利用时，有没有这样一个思考，线程池中的工作真的都执行实现了吗？
可能执行完了，可能没有。
Spring 基于以上思考，注册了线程池销毁办法。在利用敞开时，如果发现线程池存在工作没有执行完，须要期待一个指定工夫。指定工夫内工作执行如果执行结束，大快人心；如果还存在没有完结的工作，则抛弃。
为什么会抛弃工作而不是再等等？
因为如果线程池工作长时间执行，会影响整个利用的进行，进行了折中解决。
7. 三方框架中间件线程池适配
hippo4j 的指标是兼容所有框架的线程池，并能够提供监控和动静批改的能力。
目前已反对的三方框架线程池列表：
- Apache Dubbo
- Alibaba Dubbo
- RabbitMQ
- Apache RocketMQ
- SpringCloud Stream RocketMQ
- SpringCloud Hystrix
- Tomcat
- Jetty
- Undertow
反对上述框架线程池的动静变更参数和监控性能，比方：
将来 hippo4j 会反对更多三方框架线程池，如果你有好的想法也能够和我沟通。
8. 线程池运行堆栈查看
线程池运行中，工作运行进行，狐疑产生死锁或执行耗时操作。大多数程序员会抉择应用命令或者 arthas 查看线程池运行中线程的堆栈，看看其中的 Worker 都在哪个办法卡住了。
hippo4j 基于以上痛点，推出了线程池运行堆栈实时查看性能。
9. 动静线程池对性能有无影响
这可能是很多开发者放心的一个点，在这里对立回复下。
hippo4j 仅对线程池做局部外围性能加强，没有批改工作执行源代码流程，能够保障相对的平安。
其次，hippo4j 上述的性能，都是与线程池执行工作主流程外扩大的，不会影响线程池失常的执行性能。
hippo4j 反对的两种运行模式
hippo4j 为用户提供了两种运行模式，别离是轻量级的配置核心接入，和性能更齐全的服务端接入，上面都来说说各自的优缺点。
1. hippo4j config
依赖配置核心实现线程池的动静变更，已反对的配置核心有：Nacos、Apollo、Zookeeper，将来还会接入 Etcd、Consul 等。
另外，hippo4j 已反对用户自定义配置核心实现，如果应用公司自研或其它配置核心，也能够极小工作量进行引入。
应用 hippo4j config 模式的长处和有余：
- 长处：轻量级引入，能够依据我的项目中已有配置核心进行 hippo4j 的集成，无需引入其它服务，即可应用线程池参数动态化、运行时监控、报警等外围性能。
- 有余：短少可视化控制台页面，上文中形容的诸多性能不能应用。
2. hippo4j server
须要部署 hippo4j Jar 包，涵盖上文中形容的所有性能。
因为服务端外部实现了配置核心和注册核心（参考 nacos 和 eureka 实现），所以它不依赖任何三方中间件。
- 长处：性能完备，能够享受更多的服务和便当。如果利用启动的是集群，能够指定其中某一个实例的线程池批改，而 config 则是整个集群变更。
- 有余：相比拟 hippo4j config，须要额定部署一个 jar 包，减少了部署工作量。
如果最后应用 hippo4j config，想要切换到 server，两者在进行替换的时候，无需批改业务代码。
应用倡议：依据公司状况抉择，如果基本功能能够满足应用，抉择 hippo4j config 应用即可；如果心愿更多的性能，能够抉择 hippo4j server。
我的项目倒退近况
开源我的项目倒退离不开用户和贡献者的反对，小马哥梳理出最近 hippo4j 倒退近况：
- GitHub、Gitee 播种 3.2k+ star，810+ fork。
- 2022.4.12 Gitee 评比 GVP（最有价值开源我的项目）。
- 58 名我的项目贡献者为 hippo4j 添砖加瓦，这里重点感激。
- 16 家应用注销公司，生产环境正式运行 hippo4j。
- 通过墨菲平安扫描，无任何代码安全漏洞隐患。
文末结语
最初总结下，开源作者就义了每天上班和周六日的工夫做开源我的项目，如果感觉有用，麻烦各位大佬在以下两个平台 star 反对下，灰常感激～
GitHub：https://github.com/opengoofy/hippo4j
Gitee：https://gitee.com/agentart/hippo4j