仅需两步即可完成:
1. 打开 12306 项目 开源仓库主页,右上角点个 Star
2. 点击下方【同意授权检测】按钮,同意获取 API 权限进行检测
本章节文档,将在 Star 12306 仓库后正常开放展示
你是否在项目中使用线程池遇到过以下问题?
在真实业务场景中,线程池可能遇到的问题比这里描述的还要多,稀奇古怪。
笔者所经历过的项目,因为业务对线程池参数没有合理配置,就触发过几起生产事故。大概在 21 年 6 月份左右,开始在网上搜索动态线程池的项目。
在开源平台找了挺多动态线程池项目,从功能性以及健壮性而言,个人感觉不满足企业级应用。
再加上当时看了美团动态线程的文章,就对这个技术方向比较感兴趣,所以决定自己来造一个轻量级的轮子。
我觉得写一个偏中间件的框架,还能帮助用户解决实际问题,是一件很酷的事情。
GitHub:https://github.com/opengoofy/hippo4j (opens new window)
Gitee:https://gitee.com/opengoofy/hippo4j (opens new window)
通过对 JDK 线程池的增强,以及扩展三方框架底层线程池等功能,为业务系统提高线上运行保障能力。
Hippo4j 框架提供以下功能支持:
Google 或者百度搜索线程池和生产事故关键字,几页都放不下,这也间接说明了线程池是个很考验使用者技术功底的技术点。
那有没有一些技巧或者技术来尽量规避线程池使用上的问题?比如:线程池的配置应该如何选择?
我觉得大家对于线程池参数的纠结点主要有两个,无外乎设置的线程数多了或者少了。
如果预设的线程数或阻塞队列数量少了,当业务量上来,任务都在排队或者执行拒绝策略。
如果超量设置线程池的参数,无疑会造成资源浪费。
如果要修改运行中应用线程池参数,需要停止线上应用,调整成功后再发布,而这个过程异常的繁琐,如果能在运行中动态调整线程池的参数无疑会提高问题解决效率。
Hippo4j 提供了应用线程池运行时变更核心参数的功能。而且,如果应用是集群部署,可以选择修改线程池某一实例,或者修改集群全部实例,运行时生效,不需要再重启服务。
压测时可以使用 Hippo4j 动态调整线程池参数,判断线程池核心参数设置是否合理。对于开发测试来说,如果不满足可以随时调整。
很多时候,线程池出故障的时候,系统已经发生了很严重的损失。有没有一种方式,在使用的线程池即将出现问题,但还算比较可控时,触发相关报警提示给用户,进而规避该问题?
Hippo4j 基于上述问题思考,集成了四种报警策略:
支持钉钉、企业微信和飞书软件通知,下图以线程池任务运行超时报警举例:
Hippo4j 线程池提供了两种监控方式:线程池运行时数据采集监控以及客户端线程池运行实时状态查看。
1)线程池核心参数监控。
2)线程池实例运行时状态。
线程池运行时数据采集适合应用负责人巡查应用健康状态和排查问题时使用,实时状态适合排查多实例之间的运行数据状态。
上面讲的动态线程池是业务中开发人员手动创建的线程池,比如下面这个:
@Bean
@DynamicThreadPool
public ThreadPoolExecutor messageConsumeDynamicExecutor() {
String threadPoolId = "message-consume";
return ThreadPoolBuilder.builder()
.threadFactory(threadPoolId)
.threadPoolId(threadPoolId)
.dynamicPool()
.build();
}
而框架线程池指的是某些三方中间件底层使用到的线程池,比如 Dubbo、RocketMQ 等框架,这些底层框架为了增强性能选择使用线程池进行扩展。
为什么要适配这些中间件框架的线程池?
相信这是很多小伙伴的疑问。以 Dubbo 举例,当服务高并发调用时,如果 Dubbo 底层线程池没有经过个性化配置,极有可能导致线程池打满,最终导致无法提供服务。
当遇到这种情况,可以使用 Hippo4j 对 Dubbo 线程池进行核心参数调整,避免生产故障时间持续。
再举个例子,当 RocketMQ 消息积压时,可能大部分公司的解决方案是添加客户端应用节点。而这种方式虽然可以解决问题,但是问题也很明显,太复杂且资源浪费。完全可以调整 RocketMQ SDK 底层线程池的线程数来达到快速消费的逻辑,有效解决 MQ 消息堆积问题。
目前 Hippo4j 已支持的三方中间件线程池列表:
上述中间件线程池都可以在 Hippo4j 页面上操作核心参数动态变更以及监控功能,如下所示:
未来 Hippo4j 会支持更多三方框架线程池,如果你有好的想法也可以和我沟通,一起完善中间件框架适配。
如果一上来就下载 Hippo4j 的源码来看,很容易迷失进去。这里给大家画了几张图,帮助大家在阅读源码时,能够抓紧主干分支,更快上手 Hippo4j 框架源码。
如果您公司没有使用 Hippo4j 场景的话,我也建议去阅读下项目的底层原理,主要有以下几个原因:
Hippo4j 是 OpenGoofy 开源社区动态线程池框架,已有 32+ 公司生产实际使用经验,经历单节点连接数百应用考验。
至今已开源接近两年时间,期间发布 17 次 Release 版本,收获 Star 4.8k,10 位核心贡献者 Committer,101 位贡献者 Contributor。
GitHub:https://github.com/opengoofy/hippo4j (opens new window)
Gitee:https://gitee.com/opengoofy/hippo4j (opens new window)
🚀 系统提示:访问文档失败 🚀
原因:开源不易,文档仅对已 Star 12306 项目的用户开放。
操作步骤:点击下方「Gitee 项目」和「GitHub 项目」按钮 Star 项目即可。 12306 所有端的代码都会完全开源,为了更好地完善这个框架,希望大家多多支持。