通过生命周期钩子、状态快照聚合与主动探活三重机制识别“假关闭、真驻留”线程池，不依赖外部轮询且零业务侵入；劫持创建打标、定时扫描四大泄漏信号、注入关闭钩子验证优雅性、分级报警可控可溯。
直接在 JVM 进程内埋点，用 生命周期钩子 + 状态快照聚合 + 主动探活 三重机制识别“假关闭、真驻留”的线程池。不依赖外部轮询，也不侵入业务代码，上线后可长期低开销运行。
一、劫持线程池创建，打标并注册到全局台账
所有线程池（无论是否 Spring 托管）都应经由统一工厂创建，或通过 Java Agent / 类加载增强方式拦截 ThreadPoolExecutor 构造与常见 Executors 工厂方法。关键动作：
- 为每个线程池实例生成唯一 ID（如
"order-pool-20260527-001"），绑定其threadFactory名称、核心/最大线程数、队列类型及容量 - 用
WeakReference<threadpoolexecutor></threadpoolexecutor>存入全局ConcurrentHashMap<string weakreference extends executorservice>></string>，避免强引用阻碍 GC - 记录首次创建时间、调用栈前 3 行（定位配置类或初始化位置），生产环境建议脱敏路径
二、定时扫描：识别“常驻泄漏”四大信号
每 30 秒执行一次轻量扫描（避免 STW），比对台账中存活线程池的实时状态与预期行为：
-
空闲线程未回收：非核心线程空闲超
keepAliveTime * 2仍存活，且getActiveCount() == 0，但getPoolSize() > getCorePoolSize() -
队列持续积压：同一池连续 3 次扫描中
getQueue().size() > 0且getCompletedTaskCount()增速趋近于 0（单位分钟增量 -
已 shutdown 却仍有活跃线程：调用过
isShutdown() == true，但getActiveCount() > 0或getPoolSize() > 0 -
疑似被遗忘的单例池：创建超 24 小时、从未调用过
shutdown()、且getCompletedTaskCount() 的池（典型如误配的 <code>newSingleThreadExecutor）
三、注入关闭钩子，验证“优雅性”是否真实生效
仅靠状态判断不够，需结合应用生命周期确认关闭意图是否落地：
- Spring 环境下实现
SmartLifecycle，在stop()方法中主动标记对应线程池 ID 为“已发起关闭”，并触发一次台账快照 - JVM Shutdown Hook 中遍历台账，对未标记“已关闭”且
isTerminated() == false的池，强制记录为 未优雅关闭 - 检测到
awaitTermination()超时返回false后，若后续扫描中该池仍存在，即判定为“假关闭残留”
四、报警策略：分级节流 + 上下文脱敏 + 可控开关
报警本身不能成为故障源，必须可控、可追溯、低干扰：
- 默认聚合上报：每 5 分钟合并同类告警，只报新增 ID 和关键指标（如 “pool-order-pool: active=0, poolSize=10, queue=128, created=18h ago”）
- 紧急升频：单池连续 3 次被标记“已 shutdown 但 poolSize > 0”，立即转实时告警，并附最近一次
jstack -l {pid} | grep -A 5 'pool-order-pool'截图（限本地调试模式） - 敏感字段自动过滤：线程名中含
token、auth、user等关键词时，值部分替换为[REDACTED]；堆栈路径保留包名+类名，省略绝对路径 - 运行时开关：通过 JMX MBean 或 HTTP 端点（如
/actuator/threadpool-monitor/disable）动态启停监控，避免线上排障时误扰
不复杂但容易忽略的是：真正泄漏的往往不是“一直跑着”的池，而是那些“以为关了、其实没关干净”的池。哨兵的价值，在于把模糊的“感觉线程数偏高”，变成可定位、可归因、可收敛的具体 ID 和上下文。
