Java避免死锁需打破四个必要条件，核心是按固定顺序加锁、使用带超时的tryLock、缩小锁粒度、避免嵌套锁与锁升级，并优先选用无锁或线程安全类。
Java中避免死锁，核心是打破死锁产生的四个必要条件（互斥、占有并等待、不可剥夺、循环等待），重点从设计和编码习惯入手，而非依赖运行时检测。
按固定顺序获取锁
多个线程若需同时持有多个锁，必须约定并严格遵守统一的加锁顺序。例如所有线程都先获取lockA再获取lockB，而不是有的先A后B、有的先B后A——后者极易形成“线程1持A等B，线程2持B等A”的循环等待。
- 给锁对象定义明确优先级（如按类名、ID或哈希值排序）
- 封装加锁逻辑，用工具方法统一获取多把锁：先排序，再依次tryLock或synchronized
- 避免在业务代码中直接嵌套synchronized块操作不同对象
使用带超时的锁获取机制
用ReentrantLock.tryLock(long, TimeUnit)替代无条件synchronized或lock()，为获取锁设置合理超时。一旦超时失败，主动释放已持有的锁并回退，打破“占有并等待”条件。
- 超时时间不宜过短（导致频繁重试）或过长（延迟问题暴露）
- 获取多把锁时，建议逐个带超时获取；任一失败则释放前面已获得的锁
- 注意：synchronized不支持超时，必须切换到显式Lock
减少锁的粒度与作用范围
锁的范围越大、持有时间越长，发生竞争和死锁的概率越高。尽量缩小同步块，只保护真正需要互斥的代码段；优先考虑无锁方案（如ConcurrentHashMap、AtomicInteger）或读写分离（ReentrantReadWriteLock）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 避免在synchronized块内执行I/O、远程调用、复杂计算等耗时操作
- 能用局部变量/不可变对象就不用共享状态
- 对集合操作，优先选java.util.concurrent包下的线程安全类
避免嵌套锁与锁升级
一个方法内部不应在已持有锁的情况下，再去请求另一个未知来源的锁（如调用外部回调、第三方库方法）。尤其警惕“锁升级”场景：先读锁再试图转写锁（ReadWriteLock不支持升级，会死锁）。
- 不在同步方法中调用可能加锁的外部方法，除非你完全掌控其锁行为
- 使用ReadWriteLock时，明确区分读/写场景；如需写操作，单独申请写锁，不要尝试从读锁升级
- 慎用synchronized(this)或锁住整个对象，改用私有final锁对象，防止被外部误锁
基本上就这些。死锁不是偶发异常，而是并发设计缺陷的信号。与其事后排查堆栈，不如从接口设计、锁策略和资源访问路径上提前约束。简单但有效。
