死锁的典型现象是Java程序卡住、线程长时间处于BLOCKED或WAITING状态且CPU使用率极低；快速检测方法包括jstack -l查看Found 1 deadlock、JVM启动加-XX:+PrintConcurrentLocks、JConsole检测死锁；预防手段有tryLock()超时获取、按System.identityHashCode固定顺序加锁、优先使用ConcurrentHashMap等并发工具类替代手动锁。
死锁的典型现象和快速检测方法
Java 程序卡住不动、线程长时间处于 BLOCKED 或 WAITING 状态，且 CPU 使用率极低，大概率是死锁。JDK 自带工具比写代码更早发现问题：
- 用
jstack -l <pid>查看线程栈，输出中出现Found 1 deadlock.就确认了 - 在 JVM 启动时加
-XX:+PrintConcurrentLocks，可让Ctrl+\（Linux/macOS）或Ctrl+Break（Windows）触发时额外打印锁持有关系 - JConsole 连上进程后，切换到「线程」页签，点「检测死锁」按钮——它本质调的是
ThreadMXBean.findDeadlockedThreads()
用 tryLock() 主动规避嵌套锁竞争
synchronized 和 ReentrantLock.lock() 是阻塞式获取，一旦顺序不一致就容易形成环路；而 tryLock() 允许设定超时或立即失败，把“等锁”变成“抢锁 + 重试/回退”逻辑：
ReentrantLock lockA = new ReentrantLock();
ReentrantLock lockB = new ReentrantLock();
void transfer(Account from, Account to, BigDecimal amount) {
while (true) {
if (lockA.tryLock()) {
try {
if (lockB.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 执行转账
return;
} finally {
lockB.unlock();
}
}
} finally {
lockA.unlock();
}
}
// 避免忙等，短暂让出 CPU
Thread.sleep(10);
}
}
注意：tryLock(long, TimeUnit) 可能抛 InterruptedException，必须处理；永远不要在未获得锁时调用 unlock()，否则会抛 IllegalMonitorStateException。
按固定顺序加锁是最简单有效的预防手段
只要所有线程以相同顺序申请锁，环路就无法形成。关键不是“谁先谁后”，而是“全局一致”。常见做法是基于对象身份做排序：
立即学习“Java免费学习笔记（深入）”；
- 用
System.identityHashCode(obj)获取稳定哈希值（不依赖hashCode()重写） - 对多个锁对象排序后依次
lock()，释放时逆序unlock() - 避免在锁内再调用外部方法（尤其是可能获取其他锁的回调），否则顺序控制失效
示例中若两个 Account 实例要加锁，统一按 identityHashCode 升序获取：
private void lockInOrder(ReentrantLock first, ReentrantLock second) {
int h1 = System.identityHashCode(first);
int h2 = System.identityHashCode(second);
if (h1 < h2) {
first.lock(); second.lock();
} else if (h1 > h2) {
second.lock(); first.lock();
} else {
// 相同实例，只锁一次（注意：identityHashCode 理论上可能碰撞，但概率极低）
first.lock();
}
}
使用 java.util.concurrent 工具类替代手写锁逻辑
很多死锁源于对锁粒度、持有时间、协作机制理解偏差。优先用高阶并发结构：
-
ConcurrentHashMap替代HashMap + synchronized—— 它内部分段锁/ CAS，无须手动加锁 -
AtomicInteger/AtomicReference替代synchronized计数或状态更新 -
StampedLock的乐观读模式适合读多写少场景，避免读线程互相阻塞 - 需要等待条件时，用
Condition配合await()/signal()，而不是自己用wait()/notify()混搭synchronized
这些类本身已规避了常见死锁路径，且经过 JDK 团队长期压测验证。自己实现锁协调逻辑，出错成本远高于学习 API 的时间成本。
真正难的不是识别死锁，而是在业务逻辑膨胀后仍维持锁顺序的一致性；也不是选不用锁，而是判断哪些共享状态真的需要互斥——多数时候，用不可变对象、线程局部变量（ThreadLocal）或消息传递（如 BlockingQueue），比加锁更干净。
