聊聊动态线程池的9个场景（改进版）

线程池是一种基于 池化思想管理线程 的工具，使用线程池可以减少 创建销毁线程的开销，避免线程过多导致 系统资源耗尽。在 高并发以及大批量 的任务处理场景，线程池的使用是必不可少的。

如果有在项目中实际使用线程池，相信你可能会遇到以下痛点：

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

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

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

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

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

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

7. 当项目关闭时，无法做到优雅退出，大量正在运行的线程池任务被丢弃。

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

基于以上诸多痛点，小马哥着手 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. 线程池随意定义，造成服务器高负载

在系统开发的过程中，因为涉及到多人协作，难免会出现信息不互通的情况。在同一个系统，对于线程池来说，常见的是线程池随意定义。