getactivecount() 返回的并非真实活跃线程数，仅统计状态为running且已开始执行任务的worker线程，不包括刚创建未取任务或正被中断的线程，且非原子操作、对forkjoinpool无效。
Java 线程池怎么用 getActiveCount() 获取真实活跃线程数
别信返回值就是“正在跑的线程数”——getActiveCount() 只统计 Worker 状态为 RUNNING 且已开始执行任务的线程，不包括刚创建还没拿到任务、或正被 interrupt() 中断的线程。
常见错误现象：压测时看到 getActiveCount() 长期为 0，但 CPU 和日志显示任务明显在跑。原因往往是线程刚启动就快速完成任务，状态还没来得及被采样到。
- 它不是原子操作，多线程并发调用时结果可能瞬时失真
- 对
ForkJoinPool完全无效，它不继承ThreadPoolExecutor - 如果用了自定义
ThreadFactory且没调用worker.setCorePoolSize()类似逻辑，某些 JDK 版本下可能始终返回 0
监控完成任务总数：为什么 getCompletedTaskCount() 比日志计数更可靠
getCompletedTaskCount() 是线程池内部原子累加的，不受异常中断、任务重试、或日志丢行影响。但要注意它只统计成功 从队列取出并执行完毕 的任务，不包含被拒绝、未入队、或执行中抛出 RuntimeException 后未被捕获的任务。
使用场景：做 SLA 统计或对比 QPS 与实际完成量是否匹配时，优先取这个值，而不是靠 AOP 或日志 grep。
- 该值在 shutdown 后仍可读，但 shutdownNow() 后部分已完成但未更新计数的任务可能丢失统计
- 子类如
ScheduledThreadPoolExecutor会把周期性任务每次触发都算一次，不是按调度次数计 - 高并发下频繁调用对性能无明显影响，底层是
AtomicLong，比 synchronized 日志写入轻量得多
队列积压怎么看：别只盯着 getQueue().size()
getQueue().size() 返回的是当前等待队列里未被取走的任务数，但它不反映“卡住”的真实压力——比如队列是 LinkedBlockingQueue（无界），size() 持续上涨说明生产远大于消费；但如果是 ArrayBlockingQueue（有界），size 接近 capacity 才真正危险。
容易踩的坑：直接打印 getQueue() 对象本身，输出类似 java.util.concurrent.LinkedBlockingQueue@1f23a875，啥也看不出。
- 对
SynchronousQueue，size()永远是 0，它不存储任务，只做交接，积压实际体现在线程阻塞在put()上 - 若用了带优先级的
PriorityBlockingQueue，size()正确，但无法知道高优任务是否被低优任务“挡住”了 - 想查积压趋势？别每秒轮询，改用 JMX 的
QueueSize属性，或者暴露为 Micrometer 的 Gauge，避免 GC 压力
Spring Boot 里怎么安全暴露这些指标
直接把 ThreadPoolExecutor 实例塞进 @Bean 并开放 getter 是错的——它不是线程安全的监控入口，且 Spring 默认不代理其方法。正确做法是用 ThreadPoolTaskExecutor 包一层，再通过 Actuator + Micrometer 暴露。
关键点：必须调用 getThreadPoolExecutor() 拿到底层实例，否则所有 getXXX 方法都是空实现。
- 配置
spring.task.execution.pool.queue-capacity后，getQueue().remainingCapacity()才有意义，否则默认无界队列永远返回Integer.MAX_VALUE - 如果线程池是 @Async 默认使用的，记得在配置类里显式定义
taskExecutor()Bean，并启用@EnableAsync - 别在 controller 里实时调用这些方法返回 JSON——高频请求会拖慢监控端点，应聚合为定时采样（如 10 秒一次）后缓存
线程池监控最麻烦的从来不是取数，而是理解每个数字背后的状态机含义。比如 getActiveCount() == corePoolSize 不代表饱和，可能只是刚启动；而 getQueue().size() > 0 && getActiveCount() 才真正值得警觉——说明有空闲线程却没人去拿任务，大概率是队列锁竞争或任务构造太慢。
