死锁典型场景是线程间嵌套加锁顺序不一致；应按对象哈希值升序加锁、避免锁内调用外部方法、缩小同步范围；推荐用ReentrantLock.tryLock()超时机制规避；jstack和ThreadMXBean可检测死锁；LockSupport.park/unpark误用亦致逻辑死锁；根本解法是消除共享可变状态。
死锁的典型触发场景：嵌套 synchronized 锁顺序不一致
Java 中最常见死锁，是两个线程分别持有对方需要的锁，又同时申请对方持有的锁。比如 Account 类中 transfer() 方法用 synchronized(this) 锁账户实例，但若线程 A 调用 fromA.transfer(toB)，线程 B 同时调用 fromB.transfer(toA)，就极易因锁获取顺序不一致陷入死锁。
关键点不是“用了 synchronized”，而是多个锁之间缺乏全局一致的获取顺序。
- 永远按对象哈希值（或 ID）升序加锁：
if (System.identityHashCode(from) < System.identityHashCode(to)) { synchronized (from) { synchronized (to) { /* transfer */ } } } else { synchronized (to) { synchronized (from) { /* transfer */ } } } - 避免在持有锁时调用外部方法（尤其是可能获取其他锁的第三方代码）
- 不要用
synchronized修饰整个方法体，而应缩小同步块范围，只锁真正共享的临界区
使用 tryLock() 主动规避死锁
ReentrantLock.tryLock(long, TimeUnit) 是比内置锁更可控的选择——它允许超时放弃，从而打破死锁循环。
适用场景：你无法控制锁获取顺序，但能接受「重试」或「失败降级」；例如分布式 ID 生成器、缓存预热任务等对实时性要求不高但需高可用的逻辑。
立即学习“Java免费学习笔记（深入）”；
- 必须配合
lockInterruptibly()或tryLock()使用，不能混用synchronized和ReentrantLock保护同一资源 - 每次
tryLock()成功后，务必在finally块中unlock()，否则会永久泄漏锁 - 超时时间不宜过短（如 10ms），否则可能因 GC 暂停误判为锁争用；建议从 100ms 起步，结合压测调整
检测与诊断：jstack + 线程 dump 分析
运行时发现程序卡住、响应变慢，第一反应不是改代码，而是抓现场：jstack -l 输出中搜索 deadlock 或观察多个线程状态为 BLOCKED 且都在等待同一个 java.lang.Thread.State: BLOCKED (on object monitor)。
注意：jstack 只能发现已发生的死锁，不能预测；且 JDK 8+ 的 -l 参数才显示锁信息（包括 Owns Monitor 和 Waiting to Monitor）。
- 生产环境别等出问题再执行
jstack，应配置 JVM 参数-XX:+PrintGCDetails -XX:+PrintGCDateStamps并定期采集线程快照 - 避免在高峰期频繁执行
jstack，它会触发全局 safepoint，可能导致 STW 延迟 - 用
ThreadMXBean.findDeadlockedThreads()可编程检测，适合嵌入健康检查端点
LockSupport.park() 不是锁，但和死锁高度相关
很多人以为死锁只发生在 synchronized 和 ReentrantLock，其实 LockSupport.park() 配合错误的 unpark 顺序也会导致“逻辑死锁”——线程永远等不到唤醒信号。
典型例子：A 线程先 park()，B 线程后 unpark(A)，这没问题；但如果 B 先 unpark(A)，A 再 park()，那么 park() 会直接阻塞，因为许可已被提前消耗。
-
LockSupport的许可是二元的（有/无），不累积，也不报错，行为隐蔽 - 除非实现自定义同步器（如 AQS 子类），否则尽量避免直接使用
park/unpark - 调试时可用
Unsafe.monitorEnter/monitorExit替代做实验，但生产环境禁用Unsafe
死锁真正的难点不在识别，而在复现——它依赖线程调度时机和内存可见性，往往只在特定负载、JVM 版本或 GC 策略下偶发。所以与其花大量时间猜原因，不如从设计上消除多锁竞争：用不可变对象、Actor 模型（如 Akka）、或单线程事件循环（如 Netty 的 EventLoop）替代共享可变状态。
