java避免死锁需主动破坏死锁四条件之一，最有效的是破除循环等待：统一锁获取顺序，如按identityhashcode排序加锁；其次用trylock超时机制破持有并等待；再通过缩小锁粒度、解耦临界区降低冲突。

Java 中避免死锁，核心不是“防止偶然发生”，而是主动破坏死锁四条件中的至少一个。这四个条件必须**同时成立**才会死锁，缺一不可。其中互斥条件是并发安全的基础，通常不能也不应被破坏；真正可工程落地的突破口集中在另外三个——尤其是循环等待。

统一锁获取顺序（破除循环等待）

这是最有效、最常用、也最易标准化的手段。只要所有线程对同一组锁对象始终按相同规则加锁，闭环依赖就无法形成。

• 对锁对象按稳定标识排序：用 System.identityHashCode() 获取哈希值，先锁小值、再锁大值
• 业务对象不直接作锁：封装成 LockWrapper，按 ID 数值或类型名排序后依次加锁
• 使用 synchronized 时需架构层约定：例如“先锁用户主键，再锁订单ID”“先锁类锁，再锁实例锁”
• 排序动作必须前置：把待锁对象放进 List，Collections.sort() 完成后再逐个加锁，不能边判断边锁

用 tryLock + 超时机制（破除持有并等待）

synchronized 没有超时能力，一旦阻塞就是永久等待；ReentrantLock 的 tryLock(long, TimeUnit) 提供了主动退出的机会，把死锁风险转为可控失败。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 绝不连续调用 lock()：第二把锁失败时，第一把已占却无法推进，反而加剧资源独占
• 每把锁都设置合理超时（如 200ms），任一失败立即释放已获锁
• 重试时加入随机退避（如 10–100ms），避免多线程同步撞车
• 超时不是万能，但它是最后一道防线：让问题从“卡死”变成“可感知、可降级、可重试”

缩小锁粒度与解耦临界区（削弱不可剥夺+降低冲突概率）

很多“疑似死锁”其实是锁太粗、时间太长、边界不清导致的高竞争。减少持锁时间、拆分锁范围、移出危险操作，能显著降低死锁触发概率。

• 把长临界区拆成多个短块，中间插入非同步逻辑（日志、计算、校验）
• 读多写少场景优先用 ConcurrentHashMap、CopyOnWriteArrayList 或 ReentrantReadWriteLock
• 禁止在 synchronized 块内调用外部方法：RPC、DB 查询、回调函数可能暗中引入未知锁
• 计数类操作改用 LongAdder，避免 synchronized ++ 这种低效且易争抢的写法

jstack 是验证是否真死锁的黄金标准

预防再好也难保万无一失，关键是要能快速确认。jstack -l 不需要改代码、不依赖日志、不重启服务，就能精准定位死锁线程和锁依赖链。

• 执行 jps -l 找到 Java 进程 PID
• 运行 jstack -l ，重点搜索 “Found one Java-level deadlock”
• 比对输出中的 locked 和 waiting to lock 地址是否交叉成环
• 对照源码检查两个线程加锁顺序是否相反（如 Thread-0 先 A 后 B，Thread-1 先 B 后 A）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南