看门狗本质是“状态语义解读者”，需结合线程状态、时间驻留、上下文角色及虚拟线程调度特性综合判断业务是否真卡死，而非简单依赖超时或单状态判定。
因为看门狗不是“重启开关”，而是“状态语义解读者”。它不靠杀进程救系统，而靠读懂线程在 NEW/RUNNABLE/BLOCKED/WAITING/TIMED_WAITING/TERMINATED 之间每一毫秒的流转含义，来判断业务是否真卡死、还是正常等待——这一步理解错，监控就从守护变成误杀。
看门狗失效的典型根源：把状态当行为，忽略 JVM 调度语义
很多团队写的看门狗只做“超时报警”，却没区分：
- RUNNABLE ≠ 正在 CPU 上跑：它可能正卡在 OS 层 I/O 就绪队列、或刚被调度器选中但还没执行到第一行代码；盲目判定“RUNNABLE 超 2s 就告警”，会误伤大量高吞吐 IO 线程
- BLOCKED 仅针对 synchronized 锁：用 ReentrantLock 或数据库连接池等待时，线程状态仍是 RUNNABLE，此时看门狗若只盯 BLOCKED，等于对真实锁争用视而不见
-
WAITING 可能是健康空闲：线程池核心线程调用
LockSupport.park()进入 WAITING 是设计使然；但若一个支付回调线程卡在Object.wait()超过 3 秒，大概率是上游没发 notify —— 同个状态，上下文一换，意义天壤之别
非侵入式看门狗的三个关键设计锚点
所谓“非侵入”，是指不修改业务逻辑、不加埋点、不强制用特定线程模型。实现它必须锚定在 JVM 提供的原生能力上：
- 依赖 Thread.getState() 的瞬时快照能力：它是唯一无需挂起线程、不干扰调度、零成本获取状态的方式；任何试图 hook native 线程或轮询 jstack 的方案，都违背“非侵入”初衷
- 必须绑定时间戳做状态驻留分析：单次看到 WAITING 没意义，要连续 3 次采样（间隔 500ms）都落在同一状态，且该状态与线程角色预期不符（如定时任务线程不该长期 WAITING），才触发检查
- 状态组合比单状态更重要：比如一个 DB 清理线程，若连续处于 BLOCKED + RUNNABLE 交替，且 BLOCKED 持续时间逐次增长，比单纯某次 BLOCKED >200ms 更能暴露锁热点
虚拟线程时代，状态语义正在升级但不可跳过
Java 21+ 的虚拟线程让线程数量爆炸，但 Thread.State 枚举没变，只是背后调度逻辑变了：
- 虚拟线程进入 TIMED_WAITING（如 sleep）时，底层平台线程立刻释放，不影响并发吞吐；此时看门狗若仍按传统线程逻辑，把“大量 TIMED_WAITING”当作资源浪费，就会错误扩容线程池
- 虚拟线程的 BLOCKED 状态几乎消失（因 Loom 默认避免 synchronized 竞争），取而代之的是更细粒度的调度挂起；此时看门狗重点要转向
jdk.virtual.thread.schedulerJFR 事件，而非仅依赖 getState() - 但无论载体线程怎么调度，业务线程对象自身的状态快照，仍是唯一可稳定采集的“可观测入口”——跳过它去谈监控，等于在没地基时盖楼
不复杂但容易忽略：状态是 JVM 给你的唯一通用语言，看门狗不是翻译官，而是必须先学懂语法，才能把“线程活着”和“业务卡住”准确区分开。
