死锁产生的四个必要条件是互斥条件、占有并等待、不可剥夺、循环等待。互斥指资源一次仅能被一个线程持有；占有并等待指线程持有一锁又申请另一锁且不释放前者；不可剥夺指Java中锁无法被强制剥夺；循环等待指多个线程形成闭环等待链。
死锁产生的四个必要条件是什么
Java中死锁发生的前提是四个条件**同时满足**，缺一不可。这不是理论假设，而是你在线上看到 Thread.getState() == BLOCKED 且长期卡住时，背后真实运行的逻辑链条。
-
互斥条件：资源一次只能被一个线程持有。比如
synchronized(lock)或ReentrantLock.lock()默认就是互斥的——别人进不去，你占着就占着。 -
占有并等待：线程已持有一个锁（如
lockA），又去申请另一个锁（如lockB），且不释放lockA。这是最常写的错法：synchronized(lockA) { // ...中间有耗时操作或调用其他可能加锁的方法 synchronized(lockB) { ... } } -
不可剥夺：Java里没有“强制抢锁”机制。
synchronized锁不能中断释放；lock.lock()也不能被别的线程解掉——除非你自己在finally块里调用unlock()。 - 循环等待：线程 A 等 B 的锁，B 等 C 的锁，C 又等 A 的锁。典型场景是转账：A→B 和 B→A 两个方向的锁顺序不一致，环就闭合了。
为什么按固定顺序加锁能破循环等待
因为循环等待本质上是依赖关系成环，而“所有线程都先锁 id 小的账户、再锁 id 大的”这类规则，把锁获取变成了全序关系——就像大家排队只允许从左往右走，不可能绕回起点。
- 它不改变互斥、不可剥夺这些底层特性，只切断第四个条件，成本最低、效果最稳。
- 注意不是“按字母/名字排序”，而是基于对象可比的、稳定不变的属性，比如
account.getId()、resource.getHash()，避免用toString()或临时计算值。 - 如果锁对象本身没 ID，可以引入
System.identityHashCode(obj)作为保底顺序依据（但要确保多线程下该值不变）。
tryLock(timeout) 是怎么打破“占有并等待”的
tryLock(long, TimeUnit) 不是让锁变“软”，而是让你主动放弃“一边占着一边傻等”的行为模式——它把隐式阻塞，变成显式判断和可控回退。
- 失败后必须立刻释放已持有的锁（如果有），否则只是把死锁延迟成更难排查的“部分阻塞”。
finally里写lock.unlock()不够，得判断是否真的locked == true才释放。 - 超时时间不宜设太短（如 10ms），否则重试风暴拉高 CPU；也不宜太长（如 30s），失去响应性。常见取值是 100–500ms，配合指数退避更稳妥。
- 它不适合强一致性场景（如银行最终转账），但对缓存更新、日志聚合、异步通知这类“失败可重来”的逻辑很友好。
最容易被忽略的隐式锁来源
你以为只写了两处 synchronized，结果发现第三处锁藏在框架或工具方法里——比如某 ORM 的 save() 内部用了同步日志器，或某个工具类的静态方法自带类锁。
立即学习“Java免费学习笔记（深入）”；
- 检查所有被调用链路中的
synchronized方法、static方法、以及第三方库文档里明确写的“线程安全但内部加锁”说明。 - 特别警惕
java.util.Collections.synchronizedMap()这类包装器：它给每个方法加锁，但锁对象是内部的mutex，你根本没法参与排序。 - 用
jstack -l抓现场时，重点看- waiting to lock后面的地址是否和别的线程- locked对得上——这才是真·环，不是误判。
实际写转账、库存扣减、配置热加载这类多资源协同逻辑时，别靠“应该不会出问题”赌运气。四个条件里，循环等待最可控，占有并等待最容易漏，而隐式锁往往出现在你 review 十遍都没点开的那行日志打印里。
