死锁发生时CPU利用率通常明显偏低，甚至长期低于10%，因为所有死锁线程均处于BLOCKED状态，既不执行计算也不进行I/O，仅无限等待对方释放锁，JVM无法分配时间片，导致实际CPU消耗极小。

死锁发生时，CPU 利用率通常**明显偏低，甚至长期处于 10% 以下**，这是最典型的识别信号之一。

为什么死锁时 CPU 反而很低？

因为陷入死锁的线程全部卡在 BLOCKED（on object monitor） 状态，既不执行计算，也不做 I/O，只是无限等待对方释放锁。JVM 线程调度器无法分配 CPU 时间片给这些线程，导致它们“空转等待”，实际 CPU 消耗极小。

JavaScript 测试模式

使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

下载

注意区分：
• 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 是否构成闭环

不复杂但容易忽略

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南