避免死锁和活锁的关键是让线程能进能退、有秩序、可观察：统一锁获取顺序切断循环等待，用trylock+超时+随机回退打破持有并等待，缩小锁范围降低竞争，配合上线前检测与运行时监控实现可观测性。
避免死锁和活锁导致业务挂起，关键不是追求“绝对不发生”，而是让线程在竞争中能进能退、有秩序、可观察。Java 多线程里，死锁让线程卡在 BLOCKED 或 WAITING 状态彻底停摆；活锁则让线程看似活跃（RUNNABLE），却反复重试、原地打转、毫无进展——两者都会使转账失败、订单超时、接口响应停滞等真实业务场景直接挂起。
统一锁获取顺序，切断循环等待链
这是最直接有效的预防手段。只要所有线程对同一组资源加锁的顺序完全一致，就不可能形成 A→B→A 这样的闭环。
- 对锁对象按确定规则排序，比如用
System.identityHashCode()比较对象地址哈希值，始终先锁 hash 值小的对象 - 避免硬编码顺序（如“先锁账户A再锁账户B”），因为调用方无法保证传参顺序；应由方法内部动态判断并排序
- 覆盖所有路径：包括工具类、回调、异步任务触发的间接调用，都必须遵守同一套排序逻辑
用 tryLock + 超时 + 回退，打破持有并等待
不用 synchronized 或无条件 lock()，改用 ReentrantLock.tryLock(timeout, unit)，让线程不再“死等”。
- 获取第一个锁成功后，对第二个锁设置 100–500ms 超时；失败则立即释放已持锁，休眠随机时间（如 10–100ms），再重试
- 随机休眠可降低多个线程同步重试的概率，防止演变成活锁
- 若重试 N 次仍失败，应记录告警、返回业务异常（如“操作繁忙，请稍后重试”），而非无限循环
缩小锁范围，优先绕过锁
很多挂起问题其实源于“锁得太多、太久、太粗”。减少锁的使用本身就是最安全的防御。
- 避免在 synchronized 块内调用外部方法（尤其是数据库操作、HTTP 请求、回调函数），这些可能隐式引入新锁或长耗时
- 把大锁拆成细粒度锁，例如按用户 ID 取模分段加锁，而不是全局锁整个账户服务
- 能用无锁结构就不用锁：用
ConcurrentHashMap替代HashMap + synchronized，用AtomicInteger替代计数器加锁
上线前检测 + 运行时监控，早发现早干预
再好的设计也难保万无一失，必须配上可观测能力。
- 单元测试中模拟多线程并发路径，用
ThreadMXBean.findDeadlockedThreads()主动检查是否出现死锁 - 生产环境开启 JVM 参数
-XX:+PrintConcurrentLocks，或定期执行jstack <pid></pid>，搜索 “Found one Java-level deadlock” - 在核心交易流程中嵌入轻量检测：每 30 秒调用一次死锁检查，一旦发现立即触发线程 dump 并告警，便于快速定位根因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
