为什么需要动态线程池？

线程池通用痛点分析

从【定义、配置、运行、监控、销毁】全生命周期来分析

1. 规划与定义阶段：缺乏治理

  • 痛点：开发人员各自为战，随意定义线程池参数，缺乏统一的管控标准

  • 后果：系统内线程资源泛滥，在高并发下引发服务器负载过高，甚至导致应用崩溃

2. 配置与调优阶段：静态僵化

  • 痛点：线程池参数通常是硬编码或静态配置，难以评估合理值
  • 后果：参数设置过小导致吞吐量不足，设置过大浪费资源。且在业务流量波动时，无法动态调整，故障风险高

3. 运行与稳定性阶段：级联影响

  • 痛点：面对突发流量，容易出现队列积压、任务执行超时或触发拒绝策略
  • 后果：直接影响既有业务的正常响应，严重时导致业务熔断或不可用

4. 监控与运维阶段：观测缺失

  • 痛点：缺乏可视化的运行指标（活跃度、队列剩余量等）及报警机制
  • 后果：系统出现问题时（如超时、卡顿），无法第一时间确认是否为线程池瓶颈，排查效率低，故障定位难

5. 维护与销毁阶段：数据丢失

  • 痛点：原生线程池对容器关闭或应用重启的感知能力弱，无法自动执行优雅关闭
  • 后果：项目发布或重启时，内存中排队或正在执行的任务被直接丢弃，造成业务数据不一致

我的 ysyThread 动态线程池解决痛点的方案？

1. 线程池资源管理

问题

  • 在系统开发的过程中，因为涉及到多人协作，难免会出现信息不互通的情况。在同一个系统，对于线程池来说，常见的是线程池随意定义。随着系统不断开发，相同或不同语义的线程池被定义的越来越多，间接导致服务器资源严重耗损

方案

  • 在控制台或配置中心查看当前应用已有线程池，是否存在相同语义且业务可复用线程池实例，避免线程资源过度浪费。

2. 线程池参数动态变更

问题

  • 业务中使用了线程池，其中线程池的配置应该如何选择？纠结的点主要有两个，设置多了或者少了

  • 如果预设的线程数或阻塞队列数量少了，当业务量上来，会遇到两种情况，不管哪一种对业务来说都是不能接受的：

    • 预估 200ms 执行完的任务，可能会 2s 执行完，因为任务都在排队
    • 任务满了后，开始执行拒绝策略，影响正常业务

  • 如果超量设置线程池的参数，无疑会造成资源浪费，同样会造成两种情况：

    • 线程资源也是占用服务器资源的，开启的多了对服务器有一定压力
    • 如果过多的创建线程，当和其它线程池一起执行时，服务器 CPU 上下文切换也是个问题

  • 如果要修改运行中应用线程池参数，需要停止线上应用，调整成功后再发布，而这个过程异常的繁琐，如果能在运行中动态调整线程池的参数多好

方案

  • 美团技术团队基于这些痛点，推出了动态线程池的概念，催生了一批动态线程池框架

  • 可以动态修改【核心线程数、最大线程数、阻塞队列、队列容量、拒绝策略、告警间隔】等等

  • 通过dashboard-dev服务组装参数并调用Nacos接口，更新对应的配置文件。各客户端应用通过监听Nacos配置中心，实现线程池配置的实时刷新

3. 运行时通知告警

问题

  • 缺乏可视化的运行指标（活跃度、队列剩余量等）及报警机制

方案

  • 从线程池运行时监控的角度出发，内置 3 种报警策略，【线程池活跃度、阻塞队列容量、拒绝策略触发】报警

  • 通过钉钉通知（模板模式），可以扩展添加其他通知模式

4. 线程池运行监控

问题

  • 缺乏可视化的运行指标（活跃度、队列剩余量等）及报警机制

方案

  • 线程池核心参数监控、线程池实例运行时状态检查 2 种

线程池核心参数监控

  • 依托Prometheus存储和采集线程池监控数据，并通过Grafana进行可视化展示

线程池实例运行时状态

  • 线程池运行时数据实时采集，展示在前端详情页面

5. 优雅关闭防任务丢失

问题

  • 项目关闭（重新发布）时，原生线程池并且没有做任何防控措施，线程池中的任务可能没有全部完成，可能会有数据丢失

方案

  • 给线程池加入awaitTerminationMillis参数，它代表当项目关闭时，如果线程池中还有数据，等待任务完成的时间，单位毫秒

  • 但是，为什么会有awaitTerminationMillis参数，等待全部任务完成不就好了么？

  • 如果线程池里面都是耗时的任务呢？停止项目时等个几分钟甚至更长时间是无法忍受的，这个需要根据项目的实际情况评估