ThreadPoolExecutor原生方法仅提供瞬时快照且高并发下有锁竞争，无法满足监控看板对低开销、可聚合、带时间维度指标的需求；应通过ThreadFactory打标+Runnable装饰器注入监控逻辑，暴露待处理任务数、线程利用率等关键组合指标，并用Micrometer对接Prometheus实现最小可行监控路径。
为什么 ThreadPoolExecutor 的内置方法不够用
Java 原生 ThreadPoolExecutor 提供了 getActiveCount()、getCompletedTaskCount()、getQueue().size() 等方法，但它们只是瞬时快照，无法反映趋势；更关键的是，这些值在高并发下直接调用可能引发锁竞争（比如 getActiveCount() 内部会加锁遍历线程），影响业务性能。监控看板需要低开销、可聚合、带时间维度的指标，原生 API 不满足。
如何用 ThreadFactory + Runnable 包装器注入监控逻辑
不建议重写 execute() 或继承 ThreadPoolExecutor —— 容易破坏拒绝策略或生命周期管理。推荐在任务提交前做轻量包装：
- 自定义
ThreadFactory给线程打标（如poolName、threadId），便于后续关联日志与指标 - 用装饰器模式包装
Runnable：记录开始时间、捕获异常、统计执行耗时，并将指标原子更新到共享计数器（如AtomicLong或 Micrometer 的Timer） - 避免在包装器中做 I/O（如发 HTTP 请求），只做内存计数；异步上报由单独线程定时拉取
示例关键片段：
public class MonitoredRunnable implements Runnable {
private final Runnable delegate;
private final Timer.Sample sample;
public MonitoredRunnable(Runnable r, Timer timer) {
this.delegate = r;
this.sample = Timer.start(timer);
}
public void run() {
try { delegate.run(); }
finally { sample.stop(); }
}
}
哪些指标必须暴露，又容易被误读
看板上最常被误判的是「队列积压」和「活跃线程飙高」：
-
getQueue().size()≠ 待处理任务数：如果用SynchronousQueue，它永远返回 0，但任务其实在等待空闲线程 —— 此时应看getActiveCount()是否长期等于corePoolSize且getTaskCount()持续增长 -
getLargestPoolSize()是历史峰值，不是当前负载：它不会降，只增，不能用于判断是否需要扩容 - 真正关键的组合指标是：
getTaskCount() - getCompletedTaskCount()（总待处理）、getActiveCount() / getPoolSize()（线程利用率）、以及队列类型对应的「阻塞中线程数」（需反射获取workers集合状态，慎用）
用 Micrometer 对接 Prometheus 的最小可行路径
不用自己实现指标暴露端点。Spring Boot 2.0+ 默认集成 Micrometer，只需：
