生产环境线程池需可观测、可预警、可追溯，核心是采集活跃线程数、队列任务数、拒绝任务数等指标，通过Micrometer+Prometheus暴露监控数据，并配置精准告警规则与上下文信息。
生产环境的线程池不是“配好就完事”，必须可观测、可预警、可追溯。核心在于：采集真实运行指标 + 建立合理阈值 + 快速触达责任人 + 辅助定位根因。
一、关键监控指标必须采集
只看“是否存活”没意义，要盯住线程池的“呼吸节奏”和“承压状态”：
- 活跃线程数（ActiveCount）：实时反映正在执行任务的线程量，突增常意味着下游响应变慢或任务堆积
- 队列任务数（QueueSize）：比线程数更敏感，队列持续增长是线程池过载的第一信号
- 拒绝任务数（RejectedCount）：已触发拒绝策略，属严重事件，需立即告警
- 线程池状态（isShutdown / isTerminated）：意外关闭需拦截，避免服务静默降级
- 任务提交速率 & 执行完成速率（每分钟）：识别吞吐拐点，辅助容量评估
二、用Micrometer + Prometheus暴露指标
不侵入业务代码，通过标准方式暴露线程池运行时数据：
- 引入micrometer-registry-prometheus依赖，配置PrometheusMeterRegistry
- 为每个自定义线程池包装一层ThreadPoolExecutor，在构造时注册到MeterRegistry：
new ThreadPoolExecutor(...).register(registry, "biz.order.process"); - Micrometer自动暴露executor_*系列指标，如：
executor_active_threads{pool="biz.order.process"} 8
executor_queue_size{pool="biz.order.process"} 124
executor_rejected_tasks_total{pool="biz.order.process"} 3
三、Prometheus告警规则设计要点
避免误报和漏报，规则要贴合实际负载特征：
-
队列积压告警：
executor_queue_size{pool=~"biz\..*"} > 50 and
executor_queue_size{pool=~"biz\..*"} > 30 offset 2m
（当前>50且2分钟前>30，排除毛刺） -
拒绝任务告警：
increase(executor_rejected_tasks_total{pool=~"biz\..*"}[5m]) > 0
（5分钟内发生过拒绝即告警） -
线程耗尽告警：
executor_active_threads{pool=~"biz\..*"} == executor_pool_size{pool=~"biz\..*"}
and on(pool)
executor_queue_size{pool=~"biz\..*"} > 10
（活跃线程打满 + 队列还有积压，说明彻底卡死）
四、告警信息必须带上下文
收到告警不能只看到“队列大了”，要一眼知道“哪里、多大、为什么”：
- Alertmanager模板中注入标签：{{ $labels.pool }}、{{ $labels.instance }}
- 附加诊断信息：当前活跃线程={{ $value | printf "%.0f" }}，队列大小={{ $value | printf "%.0f" }}，最近1次拒绝发生在{{ $annotations.time }}
- 链接跳转到Grafana对应Dashboard面板，预设时间范围+过滤该pool，直接查看过去1小时线程数/队列/耗时热力图
- 对高频告警池（如支付回调池），在告警备注中固化排查指令：检查下游pay-service健康度、查看trace中callback-task平均耗时是否>800ms
不复杂但容易忽略：线程池命名必须规范（如biz.payment.callback）、所有池必须统一注册到MeterRegistry、拒绝策略建议用AbortPolicy并记录日志——这三步没做，监控就是摆设。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
