死锁典型场景包括多线程交叉获取锁、嵌套同步块、数据库连接池与业务锁混用、回调中反向加锁；可用tryLock()按序加锁+超时释放规避；ThreadMXBean可运行时检测；优先采用ConcurrentHashMap、LongAdder、CAS等无锁方案。
死锁发生的典型场景有哪些
Java里死锁最常出现在多个线程按不同顺序获取同一组锁时。比如线程A先锁lock1再尝试获取lock2，而线程B先锁lock2再尝试获取lock1——一旦两者都拿到第一个锁、又卡在第二个锁上，就彻底僵住。
常见触发点包括：
- 嵌套同步块（
synchronized块内调用另一个可能加锁的方法） - 数据库连接池 + 业务锁混用（如先持JDBC连接，再争抢业务
ReentrantLock） - 回调接口中反向调用（A对象调B方法，B内部又回调A的加锁方法）
如何用tryLock()主动规避死锁
ReentrantLock的tryLock(long, TimeUnit)是破局关键：它不阻塞，超时即退，给程序留出释放已有锁、重试或降级的机会。
实操要点：
立即学习“Java免费学习笔记（深入）”；
- 永远按固定顺序申请锁（比如按
System.identityHashCode(obj)排序后依次tryLock） - 超时时间不宜过长，一般设为几十毫秒；太短易失败，太长仍可能卡住
- 获取失败必须释放已持有的所有锁，否则会引发更隐蔽的资源泄漏
- 不要在
tryLock失败后立即重试——要加随机退避，避免活锁
示例逻辑：
if (lock1.tryLock(50, MILLISECONDS)) {
try {
if (lock2.tryLock(50, MILLISECONDS)) {
try {
// 执行临界区
} finally {
lock2.unlock();
}
}
} finally {
lock1.unlock();
}
}
用ThreadMXBean快速定位死锁
JDK自带的ThreadMXBean能在运行时检测死锁，比等线上报警再排查快得多。
使用方式：
- 通过
ManagementFactory.getThreadMXBean()获取实例 - 调用
findDeadlockedThreads()——返回long[]线程ID，非null即存在死锁 - 配合
getThreadInfo(ids, Integer.MAX_VALUE)拿到完整堆栈，直接定位到synchronized块或lock()调用行
注意：findDeadlockedThreads()只检测Object monitor和java.util.concurrent锁，不包含本地锁（如JNI）或数据库锁。
比加锁更优的替代方案有哪些
很多场景下，加锁本身是设计冗余。优先考虑无锁或低竞争结构：
- 用
ConcurrentHashMap代替HashMap + synchronized——读操作无锁，写冲突概率低 - 计数类需求改用
LongAdder而非synchronized ++，吞吐量高一个数量级 - 状态流转用
AtomicInteger.compareAndSet()做乐观更新，失败再重试，避免长期持锁 - 批量操作尽量合并成单次加锁（比如把10次小更新攒成一次大更新）
真正难处理的是跨多个领域对象的状态一致性——这时候得靠业务层设计隔离（如用消息队列+幂等+最终一致），而不是硬扛锁。
死锁不是性能问题，是逻辑缺陷。工具能帮你发现，但根子还在加锁顺序、粒度和必要性上。越晚加锁、越少共享、越早释放，越不容易掉进去。
