Skip to main content
Version: 1.4.2

为什么写

美团线程池文章 介绍中,因为业务对线程池参数没有合理配置,触发过几起生产事故,进而引发了一系列思考。最终决定封装线程池动态参数调整,扩展线程池监控以及消息报警等功能。

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

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

想给项目起一个简单易记的名字,类似于 Eureka、Nacos、Redis;后和朋友商量,决定命名:Hippo4j

它解决了什么问题

线程池在业务系统应该都有使用到,帮助业务流程提升效率以及管理线程,多数场景应用于大量的异步任务处理。

虽然线程池提供了我们许多便利,但也并非尽善尽美,比如下面这些问题就无法很好解决。

  • 线程池随便定义,线程资源过多,造成服务器高负载。

  • 线程池参数不易评估,随着业务的并发提升,业务面临出现故障的风险。

  • 线程池任务执行时间超过平均执行周期,开发人员无法感知。

  • 线程池任务堆积,触发拒绝策略,影响既有业务正常运行。

  • 当业务出现超时、熔断等问题时,因为没有监控,无法确定是不是线程池引起。

  • 原生线程池不支持运行时变量的传递,比如 MDC 上下文遇到线程池就 GG。

  • 无法执行优雅关闭,当项目关闭时,大量正在运行的线程池任务被丢弃。

  • 线程池运行中,任务执行停止,怀疑发生死锁或执行耗时操作,但是无从下手。

Hippo4j 很好解决了这些问题,它将业务中所有线程池统一管理,增强原生线程池系列功能。

它有什么特性

应用系统中线程池并不容易管理。参考美团的设计,Hippo4j 按照租户、项目、线程池的维度划分。再加上系统权限,让不同的开发、管理人员负责自己系统的线程池操作。

举个例子,小编在一家公司的公共组件团队,团队中负责消息、短链接网关等项目。公共组件是租户,消息或短链接就是项目。

Hippo4j 除去动态修改线程池,还包含实时查看线程池运行时指标、负载报警、配置日志管理等。

  • hippo4j-adapter:适配对第三方框架中的线程池进行监控,如 Dubbo、RocketMQ、Hystrix 等;
  • hippo4j-auth:用户、角色、权限等;
  • hippo4j-common:多个模块公用代码实现;
  • hippo4j-config:提供线程池准实时参数更新功能;
  • hippo4j-console:对接前端控制台;
  • hippo4j-core:核心的依赖,包括配置、核心包装类等;
  • hippo4j-discovery:提供线程池项目实例注册、续约、下线等功能;
  • hippo4j-example :示例工程;
  • hippo4j-message :配置变更以及报警通知发送;
  • hippo4j-monitor :线程池运行时监控;
  • hippo4j-server :Server 端发布需要的模块聚合;
  • hippo4j-spring-boot:SpringBoot Starter。