死锁典型模式是多线程以不同顺序获取同一组锁，满足互斥、占有并等待、不可剥夺、循环等待四条件；jstack -l可定位，统一加锁顺序、tryLock超时、缩小同步范围是三大预防策略。
死锁发生的典型代码模式
Java中死锁最常出现在多个线程以不同顺序获取同一组Object锁（或synchronized块）时。比如线程A先锁resourceA再尝试获取resourceB，而线程B恰好相反——这种交错加锁就是死锁温床。
常见误用场景包括：银行转账（账户A→B 和 B→A 同时发起）、数据库连接池中连接与事务锁耦合、自定义资源管理器未统一加锁顺序。
- 只要两个及以上线程互相持有对方需要的锁，且都不释放，就满足死锁的四个必要条件（互斥、占有并等待、不可剥夺、循环等待）
-
synchronized方法、synchronized(this)、synchronized(obj)都可能参与死锁；ReentrantLock同样适用，只是多了tryLock()等破局手段 - JVM不会主动检测或中断死锁线程，除非你显式调用
ThreadMXBean.findDeadlockedThreads()
如何用jstack定位死锁线程
运行中的Java进程若疑似卡死，优先用jstack抓取线程快照——它能直接标出Found one Java-level deadlock:并列出所有卷入线程的堆栈和锁状态。
执行命令：jstack -l <pid> > thread_dump.txt，其中-l参数启用锁信息输出，否则看不到locked <0x...>细节。
立即学习“Java免费学习笔记（深入）”；
关键识别点：
- 看输出中是否出现
java.lang.Thread.State: BLOCKED (on object monitor)+waiting to lock <0x...> - 对比多个线程的
locked <0x...>和waiting to lock <0x...>地址，形成闭环即为死锁 - 注意：
parking to wait for <0x...>属于Unsafe.park()，不等于synchronized阻塞，别误判
避免死锁的三种实操策略
预防优于诊断。真实项目里，靠jstack救火成本太高，应在编码阶段切断死锁路径。
统一加锁顺序：给所有可竞争资源定义全局唯一序号，要求线程始终按序号升序（或降序）获取锁。例如转账时规定：总是先锁Math.min(accountA.id, accountB.id)对应账户。
使用带超时的锁获取：改用ReentrantLock.tryLock(long timeout, TimeUnit unit)。失败后释放已持锁并重试/回退，打破“占有并等待”条件。
缩小同步范围 + 减少锁数量：避免在synchronized块内做I/O、远程调用或长耗时计算；考虑用ConcurrentHashMap代替Hashtable，用AtomicInteger代替synchronized计数。
示例：用tryLock避免转账死锁
public boolean transfer(Account from, Account to, BigDecimal amount) {
ReentrantLock firstLock = from.getLock();
ReentrantLock secondLock = to.getLock();
// 按hashcode强制顺序，避免依赖业务ID
if (firstLock == secondLock) return false;
if (firstLock.hashCode() > secondLock.hashCode()) {
ReentrantLock temp = firstLock;
firstLock = secondLock;
secondLock = temp;
}
if (firstLock.tryLock()) {
try {
if (secondLock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 执行转账逻辑
return true;
} finally {
secondLock.unlock();
}
}
} finally {
firstLock.unlock();
}
}
return false;
}
死锁不是唯一要防的并发问题
解决死锁只是并发安全的起点。实践中更常见的是活锁（如两个线程谦让式重试导致谁也进展不了）、饥饿（低优先级线程长期得不到CPU或锁）、以及volatile误用导致的可见性幻觉。
特别注意：synchronized和ReentrantLock都保证原子性+可见性，但volatile只保证可见性和禁止重排序，不保证复合操作（如i++）的原子性。
真正棘手的往往是锁粒度与性能的平衡——锁太粗，吞吐上不去；锁太细，代码复杂、易出错、甚至引入新死锁。没有银弹，只有根据压测数据反复权衡。
