Java死锁不是会让CPU爆表吗

想获取更多高质量的Java技术文章？欢迎访问 **********，持续更新优质内容，助力技术成长!

一、为什么线程会"卡死"？

上周生产环境报警群炸了——CPU使用率飙到98%！当我打开线程dump一看，二十几个线程都在BLOCKED状态，像极了早高峰的三环路。这时候老板冲过来问："不是说死锁会卡死线程吗？怎么CPU还这么高？"

死锁的四个必要条件（交通堵塞版）：

1. 互斥条件：单行道只能过一辆车（资源独占）
2. 请求与保持：占着左转道还想直行（持有资源不释放）
3. 不可剥夺：没有交警强制移车（系统不能回收资源）
4. 循环等待：四辆车十字路口互不相让（环形依赖）

// 经典转账死锁案例
public void transfer(Account from, Account to, int amount) {
    synchronized (from) {          // 锁住转出账户
        Thread.sleep(100);        // 模拟网络延迟
        synchronized (to) {       // 尝试锁住转入账户
            from.withdraw(amount);
            to.deposit(amount);
        }
    }
}
// 当两个线程互相转账时就会死锁

二、死锁到底会不会拉高CPU？

纯死锁不会！但是...

当线程进入BLOCKED状态时，会主动让出CPU时间片。这时候CPU应该很闲才对，就像堵车时司机都熄火等待。但实际情况往往更复杂：

CPU升高的三大间接原因：

1. 线程池的报复性补偿：大量线程被阻塞，线程池疯狂创建新线程
2. 自旋锁的忙等待：某些锁实现会循环尝试获取锁（CAS操作）
3. 监控系统的自救行为：健康检查、日志打印等补偿机制

最近处理的一个真实案例：某支付系统死锁后，线程池从50线程暴涨到500线程，导致CPU飙升。用jstack抓取线程快照发现，大量线程卡在ThreadPoolExecutor$Worker.run()中的getTask()调用。

三、线程的六种状态

通过jstack输出的线程状态，就能看穿JVM的内心戏：

诊断死锁的黄金命令：

# 生成线程dump
jstack <pid> > thread_dump.log

# 查找死锁关键词
grep -A 20 "deadlock" thread_dump.log

四、CPU飙升时的破解指南

1. Arthas

# 监控线程状态
thread -n 5

# 查看死锁
thread -b

2. VisualVM

3. 压箱底的脚本

#!/bin/bash
# 监控CPU与线程数
while true; do
    date +"%T"
    top -bn1 | grep java
    jstack <pid> | grep -E "BLOCKED|RUNNABLE" | wc -l
    sleep 2
done

五、预防死锁的六个狠招

1. 锁排序法

public void transfer(Account a, Account b, int amount) {
    Account first = a.id < b.id ? a : b;
    Account second = a.id < b.id ? b : a;
    
    synchronized (first) {
        synchronized (second) {
            // 转账逻辑
        }
    }
}

2. 使用tryLock

Lock lock1 = new ReentrantLock();
Lock lock2 = new ReentrantLock();

if (lock1.tryLock(1, TimeUnit.SECONDS)) {
    try {
        if (lock2.tryLock(1, TimeUnit.SECONDS)) {
            try {
                // 业务逻辑
            } finally {
                lock2.unlock();
            }
        }
    } finally {
        lock1.unlock();
    }
}

3. 其他必杀技

• 设置合理的锁超时时间
• 避免在持锁时调用外部服务
• 使用并发集合代替同步块
• 定期执行死锁检测脚本

六、一个真实案例全流程复盘

背景：某电商平台大促期间，订单服务CPU持续95%+，但TPS为0。

排查过程：

1. top -Hp <pid>找到高CPU线程ID
2. 将线程ID转十六进制：printf "%x" 114514
3. jstack <pid> | grep -A 30 0x1bf52
4. 发现多个线程BLOCKED在同一个锁上
5. 检查代码发现嵌套的synchronized块
6. 使用ReentrantLock改写并增加tryLock

优化效果：

• CPU使用率从95%降至35%
• TPS从0恢复到1200/s
• 99%响应时间从30s降至200ms

想获取更多高质量的Java技术文章？欢迎访问 **********，持续更新优质内容，助力技术成长!