java线程池可通过threadpoolexecutor的getter方法实时获取运行指标，如getactivecount()、getqueue().size()等；需结合prometheus用micrometer手动注册gauge，并自定义rejectedexecutionhandler记录拒绝事件，同时注意工作队列积压与线程空闲并存的典型现象。
怎么获取线程池的实时运行指标
Java 线程池本身不主动上报状态，但 ThreadPoolExecutor 提供了多个公开的 getter 方法，可随时读取关键运行时数据。这些值不是快照，而是当前瞬时状态，适合在监控埋点或健康检查中调用。
常用指标及对应方法：
-
getPoolSize()：当前线程总数（包括空闲和活跃） -
getActiveCount()：当前正在执行任务的线程数 -
getQueue().size()：任务队列中待处理任务数（注意：对SynchronousQueue永远返回 0） -
getCompletedTaskCount()：已完成任务总数（含异常结束的） -
getLargestPoolSize()：历史最大线程数（可用于判断是否频繁扩容）
⚠️ 注意：getActiveCount() 返回的是「正在 run()」的线程数，不是「持有锁」或「阻塞中」的线程数；若任务内部有 I/O 或 sleep，它仍被计入活跃，但实际不消耗 CPU。
如何安全地暴露线程池指标给 Prometheus
Spring Boot 项目常用 micrometer + prometheus 实现指标采集。不能直接把 ThreadPoolExecutor 注册为 Bean 并暴露，因为它的字段不是线程安全的聚合视图，且 Micrometer 不识别原生 JDK 线程池。
立即学习“Java免费学习笔记（深入）”；
正确做法是手动构建 Gauge，定期拉取并上报：
// 假设 yourThreadPool 是 @Bean 的 ThreadPoolExecutor
Gauge.builder("threadpool.active", yourThreadPool, tp -> (double) tp.getActiveCount())
.register(meterRegistry);
Gauge.builder("threadpool.queue.size", yourThreadPool,
tp -> (double) tp.getQueue().size())
.register(meterRegistry);
关键细节：
- 避免在
Gaugelambda 中调用耗时操作（如遍历大队列），否则拖慢整个 /actuator/prometheus 接口 - 如果线程池使用
PriorityBlockingQueue，size()是 O(1)，但peek()或toArray()可能触发排序，慎用 - 多个线程池需用不同前缀命名（如
threadpool.cache.active、threadpool.io.queue.size），否则指标会覆盖
线程池拒绝策略触发时怎么记录告警
仅靠指标水位无法感知任务是否被丢弃。必须自定义 RejectedExecutionHandler，在拒绝发生时打日志、发事件或推指标。
推荐写法：
new RejectedExecutionHandler() {
private final Counter rejectedCounter = Counter.builder("threadpool.rejected")
.tag("name", "io-pool").register(meterRegistry);
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
rejectedCounter.increment();
log.warn("Task {} rejected by {}", r.getClass().getSimpleName(), executor);
}
};
常见陷阱：
- 不要在 handler 里同步提交新任务到同一线程池（极易死锁或无限递归）
- 不要在 handler 中做复杂对象序列化或远程调用（拒绝本就说明系统承压，再加开销会恶化）
- 若用
CallerRunsPolicy，它不抛异常也不丢任务，但会把任务退回到调用线程执行——这会让上游线程卡住，监控上表现为「上游接口 RT 突增」，而非线程池拒绝率上升
为什么线程池监控总显示「空闲但队列积压」
典型现象：监控看到 active=0、poolSize=coreSize，但 queue.size > 0，且任务迟迟不消费。这不是监控不准，而是线程池工作模式的自然表现。
根本原因：
- 线程池不会主动创建超过
corePoolSize的线程，除非队列已满（此时才触发扩容逻辑） - 如果任务都是短时 CPU 密集型，线程很快空闲，但新任务持续涌入，就会堆积在队列
- 若用
allowCoreThreadTimeOut(true)，核心线程也可能超时回收，进一步加剧「有队列却没人干活」的假象
排查建议：
- 查
getLargestPoolSize()是否长期等于corePoolSize：若是，说明从未触发扩容，队列容量可能设得过大 - 对比
getCompletedTaskCount()的增长速率和getQueue().size()：若前者远小于后者，说明消费能力不足，需调低任务处理耗时或增加并发度 - 注意：某些异步框架（如 Netty 的 EventLoopGroup）包装了线程池，其「队列」可能是链表或无界结构，
size()不一定反映真实积压
线程池监控真正难的不是采集数据，而是理解「活跃线程数」「队列长度」「拒绝次数」三者之间的因果关系——它们从不同角度指向同一个瓶颈，但各自掩盖了部分上下文。
