死锁表现为线程卡住、CPU占用低但程序无响应；可用jstack搜deadlock或jconsole点击Detect Deadlock定位；须按固定顺序加锁、用tryLock超时机制，并避免synchronized与ReentrantLock混用。
Java 中死锁的实际表现和快速定位方法
线程卡住不动、CPU 占用低但程序无响应，大概率是死锁。JVM 自带工具能直接抓到，不用猜。
-
jstack <pid></pid>输出里搜deadlock，如果有，会明确标出哪些线程在等哪些锁，以及它们各自持有什么锁 - 使用
jconsole或VisualVM连上进程，在「Threads」页点「Detect Deadlock」按钮，比看日志更直观 - 注意：只有“互相持有并等待”才算 JVM 认定的死锁；单个线程等一个没释放的锁（比如 synchronized 方法里调了阻塞 I/O），不算死锁，但也会卡住——别混淆
破坏“循环等待”条件：按固定顺序加锁最有效
四个必要条件里，“循环等待”最容易被代码控制。只要所有线程以同一顺序获取多个锁，死锁就不可能发生。
- 给锁对象定义明确优先级，比如按
System.identityHashCode(objA) 决定谁先 lock - 避免在持有锁 A 时，动态决定下一步要锁 B 还是 C；把锁的顺序写死在逻辑里，比如总是先
lock(account1)再lock(account2) - 用
ReentrantLock.tryLock(long, TimeUnit)带超时尝试，失败就释放已持锁并重试，比死等安全得多
synchronized 和 ReentrantLock 在死锁场景下的关键差异
两者都会导致死锁，但排查和控制能力差很多。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
synchronized是 JVM 层隐式锁，jstack能显示它，但没法中断、没法超时、没法公平调度 -
ReentrantLock支持tryLock()、lockInterruptibly()、可配置公平性，更适合需要主动防死锁的场景 - 别混用：同一个资源，一部分用
synchronized，另一部分用ReentrantLock，等于自己造黑盒，jstack 看不到后者对前者的阻塞关系
银行家算法在 Java 里不实用，别硬套
教科书常提银行家算法，但它要求提前声明全部资源需求，而 Java 的锁不是资源池里的“可分配单位”，没法预估。
立即学习“Java免费学习笔记（深入）”；
- 没有现成的
BankerAlgorithmManager类，也没法给每个synchronized块注册“最大需求数” - 真实项目中，用锁顺序 + 超时 + 定期 dump 线程栈，比模拟资源分配表更可靠
- 如果真有复杂资源依赖（比如数据库连接 + 文件句柄 + 外部 API 令牌），应该拆成独立服务或用消息队列解耦，而不是靠算法调度锁
真正难的不是理解四个条件，而是在线程交织不可控时，确保锁顺序不被业务逻辑绕开。比如工具方法悄悄换了锁顺序，或者用了反射、代理、AOP，都可能让表面有序的加锁变成实际循环等待。
