死锁发生时CPU利用率通常明显偏低，甚至长期低于10%，因为所有死锁线程均处于BLOCKED状态，既不执行计算也不进行I/O，仅无限等待对方释放锁，JVM无法分配时间片，导致实际CPU消耗极小。
死锁发生时，CPU 利用率通常**明显偏低，甚至长期处于 10% 以下**，这是最典型的识别信号之一。
为什么死锁时 CPU 反而很低？
因为陷入死锁的线程全部卡在 BLOCKED（on object monitor） 状态，既不执行计算，也不做 I/O，只是无限等待对方释放锁。JVM 线程调度器无法分配 CPU 时间片给这些线程，导致它们“空转等待”，实际 CPU 消耗极小。
注意区分：
• RUNNABLE 状态 + 高 CPU → 可能是无限循环、密集计算或 GC 压力大；
• BLOCKED 状态 + 低 CPU → 更倾向锁竞争或死锁；
• WAITING / TIMED_WAITING → 多为正常阻塞（如 await、join、sleep），不一定异常。
结合监控看更准
- 观察线程池活跃线程数是否长期满载（如 200/200），但 CPU 却不到 20%
- 检查业务请求响应变慢或超时，日志停止输出新记录
- 对比历史基线：若同一时段 CPU 突然从 60%+ 掉到个位数，且无发布或流量变化，需高度怀疑
别只盯 CPU，要联动看线程状态
单看 CPU 容易误判。真正可靠的方式是：
→ 先发现 CPU 异常走低 + 请求无响应
→ 立即用 jstack -l
→ 搜索文件中是否有 "Found one Java-level deadlock"
→ 若有，再核对各线程的 waiting to lock 和 locked 是否构成闭环
不复杂但容易忽略
