Java死锁典型场景包括：①多线程以不同顺序获取同一组Lock或synchronized对象，如银行转账中线程A先account1后account2、线程B反之；②嵌套同步且锁对象不一致。
死锁发生的典型场景有哪些
Java里死锁最常出现在多个线程按不同顺序获取同一组 Lock 或 synchronized 对象时。比如线程A先锁 account1 再尝试锁 account2，而线程B反向操作——这是银行转账类代码的高发区。另一个常见点是嵌套同步：synchronized 方法内部又调用另一个需要锁的同步方法，且锁对象不一致。
如何用锁顺序策略预防死锁
核心原则是让所有线程以**相同顺序**获取锁。实际操作中，可对锁对象定义唯一、可比较的标识（如ID或哈希值），再按升序加锁：
long id1 = account1.getId();
long id2 = account2.getId();
if (id1 < id2) {
synchronized (account1) {
synchronized (account2) { /* 转账逻辑 */ }
}
} else {
synchronized (account2) {
synchronized (account1) { /* 转账逻辑 */ }
}
}- 避免用
System.identityHashCode()作排序依据——它不保证跨JVM稳定，且可能冲突 - 若使用
ReentrantLock，必须配合tryLock(long, TimeUnit)设置超时，否则仍可能卡在等待上 - 注意：这种顺序规则要全局一致，不能一部分代码按ID、另一部分按名称排序
用 tryLock() 主动规避死锁等待
ReentrantLock.tryLock() 是少数能打破“持有并等待”条件的手段。它不会阻塞，失败后可释放已持锁并重试或回退：
if (lock1.tryLock(10, TimeUnit.MILLISECONDS)) {
try {
if (lock2.tryLock(10, TimeUnit.MILLISECONDS)) {
try {
// 执行临界操作
} finally {
lock2.unlock();
}
}
} finally {
lock1.unlock();
}
}- 超时时间不宜设为0（立即返回）——容易导致忙等；也不宜过长（失去防死锁意义）
- 必须严格遵循“先成功加锁，再尝试下一个；任一失败就释放前面所有已获锁”
- 注意：
synchronized没有等价机制，一旦进入就无法中断或超时
检测与诊断死锁的实用手段
开发阶段靠人工很难覆盖所有线程交织路径，得依赖工具辅助：
立即学习“Java免费学习笔记（深入）”；
- JDK自带
jstack—— 输出中搜deadlock，会明确标出互相等待的线程和锁对象 - JConsole 或 VisualVM 的“线程”页签，点击“Detect Deadlock”按钮可实时扫描
- 生产环境慎用
ThreadMXBean.findDeadlockedThreads()，它会触发全局safepoint，短暂停顿 - 如果日志里反复出现
java.lang.Thread.State: BLOCKED (on object monitor)且堆栈长期不变，很可能是死锁前兆
真正难处理的不是明显双线程互等，而是涉及3个以上锁、或混用 synchronized 和 Lock 的链式等待——这种得靠锁顺序统一 + 静态分析工具（如FindBugs的 DL_DEADLY_ELSEWHERE 规则）提前拦截。
