Java死锁需主动预防：统一按System.identityHashCode()升序加锁、用ReentrantLock.tryLock()实现超时与可中断、避免同步块内调用外部方法，同步块仅做数据操作。
Java 中死锁无法靠语言自动检测或避免，必须从设计和编码层面主动预防——最有效的方式是统一锁获取顺序、减少锁粒度、避免嵌套等待，以及优先使用 java.util.concurrent 包中无锁或可中断的工具。
统一锁获取顺序：按对象哈希值排序加锁
多个线程以不同顺序请求同一组锁时，极易形成环路等待。解决办法不是靠“约定”，而是强制执行确定性顺序。
- 对要加锁的多个对象（如
accountA和accountB），按其System.identityHashCode()值升序排列，只允许按此顺序获取锁 - 注意不能用
obj.hashCode()（可能被重写），必须用System.identityHashCode()保证唯一性和稳定性 - 若涉及继承体系，需确保所有参与排序的对象类型一致，否则哈希值比较失去意义
- 示例逻辑：
int h1 = System.identityHashCode(obj1);
int h2 = System.identityHashCode(obj2);
if (h1 < h2) {
synchronized(obj1) { synchronized(obj2) { /* ... */ } }
} else if (h1 > h2) {
synchronized(obj2) { synchronized(obj1) { /* ... */ } }
} else {
// h1 == h2：极小概率，可加额外标识（如类名+地址）再判别
}
用 tryLock() 替代 synchronized 实现超时与可中断
当必须尝试获取多个锁，且无法严格保证顺序时，ReentrantLock.tryLock(long, TimeUnit) 是更安全的选择。
- 它不会无限阻塞，可在指定时间内放弃，打破死锁必要条件中的“不可剥夺”
- 配合
Thread.interrupted()或lockInterruptibly()，支持外部中断，便于资源回收 - 必须在
finally块中显式调用unlock()，否则会导致锁泄漏——这是比synchronized更易出错的地方 - 不要在持有部分锁失败后直接重试，应释放已获锁再退避，否则可能引发活锁
避免在同步块内调用外部可重入方法（尤其是 wait()、notify() 或第三方回调）
看似安全的同步代码，一旦内部触发未知锁行为，就可能引入隐蔽依赖链。
立即学习“Java免费学习笔记（深入）”；
- 例如在
synchronized(obj) { obj.notify(); }看似无害，但如果obj.notify()内部又调用了另一个需同步的方法，就可能反向持锁 - 尤其警惕日志框架（如 Log4j）、序列化工具、Spring AOP 代理等，它们可能在任意方法调用中插入同步逻辑
- 推荐策略：同步块尽量只做数据搬运或状态更新，耗时操作、I/O、回调、日志记录全部移出同步范围
- 若必须调用外部方法，先复制所需数据，再解锁，再调用——即“先复制、后处理”原则
真正棘手的死锁往往不出现在教科书式的双锁场景里，而藏在跨模块协作、异步回调嵌套、或动态代理注入的锁中。与其事后排查堆栈，不如从第一个 synchronized 块开始就问一句：这个锁的生命周期是否可控？有没有其他路径能触达它？
