单看getPoolSize()波动易误判，因其不区分核心线程回收、异常终止、外部重建等场景；需联动TERMINATED线程增量、未捕获异常日志、getCompletedTaskCount()与getTaskCount()差值及队列积压情况综合分析。
直接看 getPoolSize() 的波动本身意义有限，关键是要结合它背后的真实行为——线程频繁退出与重建，往往不是“线程挂了再拉起”，而是线程池在压力、异常或配置误用下被动销毁又新建，属于隐性资源震荡。排查难点不在指标获取，而在区分“正常伸缩”和“病态震荡”，以及定位触发源。
为什么单看 getPoolSize 波动容易误判
ThreadPoolExecutor 的 getPoolSize() 返回当前存活的线程总数，但它不区分：
- 是核心线程因空闲被回收（
allowCoreThreadTimeOut=true），还是非核心线程被自然淘汰； - 是任务执行中抛出未捕获异常导致线程终止（JVM 级退出），还是线程主动完成并退出；
- 是线程池被外部代码反复
shutdown()+new，还是内部策略触发重建。
例如：每分钟 getPoolSize 在 8→12→6→10 间跳变，可能只是 I/O 密集型任务的合理伸缩；但如果伴随大量 java.lang.Thread.run 异常日志、Thread.State.TERMINATED 突增、或 jstack 中反复出现相同线程名的新实例，就是危险信号。
必须联动的 3 类监控数据
仅盯 getPoolSize 就像只看心跳不量血压。实战中需实时比对：
-
线程生命周期事件：通过
ThreadMXBean定期调用getThreadInfo(tid)，统计TERMINATED状态线程的每分钟增量。若该值持续 > 5–10 次/分钟，且与getPoolSize下降同步，基本确认线程非正常退出； -
线程内异常堆栈：在
Thread.UncaughtExceptionHandler中统一埋点，记录线程名、异常类型、堆栈首行（如NullPointerException或IOException: Broken pipe）。高频同类异常指向具体业务模块缺陷； -
线程池内部计数器：除
getPoolSize()，必须同时采集：
•getCompletedTaskCount()（完成任务数）与getTaskCount()（总提交数）的差值突增 → 说明大量任务被拒绝或线程崩溃前未完成；
•getQueue().size()长期 > 0 且getPoolSize却在下降 → 线程已死，但队列积压，典型“线程泄漏+退出”混合故障。
快速定位退出根源的实操路径
发现异常波动后，按顺序执行：
-
查 jstack 快照对比：间隔 30 秒连续抓两次
jstack，用脚本提取所有线程名（如pool-1-thread-开头），对比新增/消失的线程 ID 和创建时间戳。若同一名称线程反复出现又消失，说明线程池在重建线程而非复用； -
过滤 JVM 日志关键词：搜索
"thread died"、"Uncaught exception"、"shutting down"、"interrupted"。特别注意日志时间是否紧邻getPoolSize下跌时刻； -
检查线程池构造逻辑：重点审计是否在循环或请求中 new ThreadPoolExecutor（常见于 Spring @Scope("prototype") Bean 或工具类静态方法）；是否调用了
shutdownNow()后未等待就重新 submit；是否设置了过短的keepAliveTime（如 100ms）导致线程刚建即毁。
一个真实场景的判断链
某支付回调服务出现 RT 波动：
- 监控显示
getPoolSize在 20→5→18→4 间 2 分钟内震荡 6 次； - 同步发现
TERMINATED线程每分钟新增 120+，UncaughtExceptionHandler日志中 92% 是SSLException: handshake timed out； - 查代码发现：回调处理中使用了自建
OkHttpClient，其连接池未复用，每次请求新建线程池，且未设置连接超时兜底； - 结论：不是线程池问题，而是下游 HTTPS 握手失败触发线程内未捕获异常 → 线程终止 → 外层逻辑重建线程池 → 资源震荡。
解决方式不是调大线程池，而是修复 HTTP 客户端配置并包裹网络调用。
