作者：沉默王二
Java 程序员进阶之路：https://tobebetterjavaer.com

大家好，我是二哥呀。

最近有不少球友跑过来问我要项目，说自己写的秒杀/商城/RPC 实在是烂大街了，问我要一些轮子项目，比如说框架啊、中间件啊，只能说，不是这些项目烂大街，是一年更比一年卷啊。

以前你简历上写瑞吉外卖、谷粒商城，没啥大问题，现在HR/面试官都经过教育了，简历上再写这些确实容易被“已读不回”。

二哥最近也没闲着，给大家又找了一个硬核的开源项目 Hippo4j，目前在 GitHub 上已经有 3.7k 的 star 了，作者也是我的好朋友，文档也比较齐全，强烈推荐给大家。

Hippo4j 是 OpenGoofy 开源社区动态线程池框架，已有 30+ 公司生产实际使用经验，经历单节点连接数百应用考验。不吹牛哈，这些是已经在用的公司。

通过对 JDK 线程池的增强，以及扩展三方框架底层线程池等功能，为业务系统提高线上运行保障能力。

项目背景

你是否在项目中使用线程池遇到过以下问题？

• 创建线程池核心参数不好评估，随着业务流量的波动，极有可能出现生产故障。
• 不支持优雅关闭，当项目关闭时，大量正在运行的线程池任务被丢弃。
• 不支持运行时监控，使用过程中业务无响应，不知道是不是线程池引起。
• 三方框架 RocketMQ、Dubbo 等线程池无法动态修改参数，修改后只能重启应用。

在真实业务场景中，线程池可能遇到的问题比这里描述的还要多，稀奇古怪。

作者经历过不少大型项目，因为业务对线程池参数没有合理配置，就触发过几起生产事故。大概在 21 年 6 月份左右，作者开始在网上搜索动态线程池的项目。

在开源平台找了挺多动态线程池项目，从功能性以及健壮性而言，个人感觉不满足企业级应用。

因为对动态线程池比较感兴趣，加上想写一个有意义的项目，所以决定自己来造一个轻量级的轮子。

GitHub：https://github.com/opengoofy/hippo4j

Gitee：https://gitee.com/agentart/hippo4j

核心功能

Hippo4j 框架提供以下功能支持：

• 全局管控 - 管理客户端应用全部线程池实例。
• 动态变更 - 应用运行时动态变更线程池核心参数。
• 通知报警 - 内置多种报警通知策略，线程池活跃度、容量水位、拒绝策略以及任务执行时间超长。
• 数据采集 - 支持多种方式采集线程池数据，包括但不限于：日志、内置采集、Prometheus、InfluxDB、ElasticSearch 等。
• 运行监控 - 实时查看线程池运行时数据，自定义时间内线程池运行数据图表展示。
• 功能扩展 - 支持线程池任务传递上下文；项目关闭时，支持等待线程池在指定时间内完成任务。
• 多种模式 - 内置两种使用模式：依赖配置中心 和 无中间件依赖。
• 容器管理 - Tomcat、Jetty、Undertow 容器线程池运行时查看和线程数变更。
• 框架适配 - Dubbo、Hystrix、RabbitMQ、RocketMQ 等消费线程池运行时数据查看和线程数变更。
• 变更审核 - 提供多种用户角色，普通用户变更线程池参数需要 Admin 用户审核方可生效。
• 动态化插件 - 内置多种线程池插件，支持用户自定义插件以及运行时扩展。
• 多版本适配 - 经过实际测试，已支持客户端 SpringBoot 1.5.x => 2.7.5 版本（更高版本未测试）。

应用场景

1. 动态调参

业务中使用了线程池，十个程序员可能有九个都在犯嘀咕，这线程池的配置应该如何选择？

我觉得犯纠结的点主要有两个，无外乎设置的线程数多了或者少了。

• 如果预设的线程数或阻塞队列数量少了，当业务量上来，任务都在排队或者执行拒绝策略。
• 如果超量设置线程池的参数，无疑会造成资源浪费。

如果要修改运行中应用线程池参数，需要停止线上应用，调整成功后再发布，而这个过程异常的繁琐，如果能在运行中动态调整线程池的参数无疑会提高问题解决效率。

如果应用是集群部署，Hippo4j 可以选择修改线程池 某一实例，或者修改集群全部实例，运行时生效，不需要再重启服务。

压测时可以使用 Hippo4j 动态调整线程池参数，判断线程池核心参数设置是否合理。对于开发测试来说，如果不满足可以随时调整。

2. 告警策略

从线程池运行时监控的角度出发，hippo4j 内置 4 种报警策略，线程池活跃度、阻塞队列容量、拒绝策略触发以及任务运行超时报警。

• 线程池活跃度：假设阈值设置 80%，线程池最大线程数 10，当线程数达到 8 发起报警。
• 阻塞队列容量：假设阈值设置 80%，阻塞队列容量 100，当容量达到 80 发起报警。
• 触发拒绝策略：当线程池任务触发了拒绝策略时，发起拒绝策略报警。
• 任务运行超时：假设单个任务超时为 1000ms，任务执行超过该时间发起报警。

Hippo4j 支持钉钉、企业微信和飞书软件通知，线程池任务运行超时报警示例：

3. 线程池监控

Hippo4j 内部提供了两种监控方式：线程池核心参数监控以及线程池实例运行时状态检查。

1）线程池核心参数监控。

2）线程池实例运行时状态。

通过两种监控方式，可以方便快捷掌握线程池运行时的数据状态，可以用作健康巡查以及历史问题复盘。

4. 中间件线程池

Hippo4j 的目标是兼容所有中间件的线程池，并可以提供监控和动态修改的能力。

Q：为什么要适配这些中间件框架的线程池？

A：相信这是很多小伙伴的疑问。以 Dubbo 举例，因为当服务高并发调用时，如果 Dubbo 底层线程池没有经过个性化配置，极有可能导致线程池打满，最终导致无法提供服务。

当遇到这种情况，可以使用 Hippo4j 对 Dubbo 线程池进行核心参数调整，避免生产故障时间持续。

目前 Hippo4j 已支持的三方中间件线程池列表：

• Apache Dubbo
• Alibaba Dubbo
• RabbitMQ
• Apache RocketMQ
• SpringCloud Stream RocketMQ
• SpringCloud Hystrix
• Tomcat
• Jetty
• Undertow

上述中间件线程池都可以在 Hippo4j 页面上操作核心参数动态变更以及监控功能，如下所示：

未来 Hippo4j 会支持更多三方框架线程池，如果你有好的想法也可以和我沟通。

深入原理

如果您公司没有使用 Hippo4j 场景的话，我也建议去阅读下项目的底层原理，主要有以下几个原因：

• 为了提高代码质量以及后续的扩展行为，运用多种设计模式实现高内聚、低耦合。
• 框架底层依赖 Spring 框架运行，并在源码中大量使用 Spring 相关功能。
• 运用 JUC 并发包下多种工具保障多线程运行安全，通过实际场景理解并发编程。
• 借鉴主流开源框架 Nacos、Eureka 实现轻量级配置中心和注册中心功能。
• 自定义 RPC 框架实现，封装 Netty 完成客户端/服务端网络通信优化。
• 通过 CheckStyle、Spotless 等插件规范代码编写，保障高质量代码行为和代码样式。

配套教程

那看到这，可能小伙伴们都蠢蠢欲动了，怎么才能快速跑起来这个项目呢？作者已经替大家考虑到了，所以上线了官方的帮助文档，写得非常详细。

地址：https://hippo4j.cn

总结

Hippo4j 至今已开源接近两年时间，期间发布 17 次 Release 版本，共 30+ 公司部署生产使用，收获 Star 4.6k，10 位核心贡献者 Committer，92 位贡献者 Contributor。

这个项目还是非常值得信赖的，不管是工作党，还是学生党，我想都能够从中学到知识，提升技术，写到简历上，也绝对是加分项。

以上，希望帮助到大家。

ending

一个人可以走得很快，但一群人才能走得更远。二哥的编程星球已经有 1900 多名 球友加入了，如果你也需要一个良好的学习环境，戳链接