避免死锁靠设计约束与运行时防护，核心是破坏循环等待：统一锁获取顺序、用tryLock+超时兜底、缩小锁粒度；排查依赖jstack、JConsole和ThreadMXBean主动探测。
避免死锁不是靠“运气”，而是靠设计约束和运行时防护；排查死锁也不依赖猜测，而要借助 JVM 提供的可观测能力。核心思路很明确：破坏死锁四条件中的任意一个，尤其是循环等待——这是最可控、最常被工程落地的突破口。
统一锁获取顺序（治本之策）
只要所有线程对同一组资源始终按相同规则加锁，循环等待链就无法形成。这不是建议，是必须强制执行的设计契约。
- 用 System.identityHashCode() 为锁对象生成稳定序号，排序后依次加锁（推荐用于 ReentrantLock）
- 业务对象（如 User、Order）不直接作为锁，封装成 LockWrapper，并按 ID 数值或类型名字典序排序
- 若必须用 synchronized，需在架构层约定死顺序，例如“先锁 Class 对象，再锁实例；先锁用户域，再锁订单域”
- 排序逻辑要前置——把待锁对象放进 List，调用 Collections.sort() 完成后再逐个 lock()，不能边判边锁
用 tryLock + 超时兜底（防御性保障）
synchronized 没有超时能力，一旦卡住就是永久阻塞。换成 ReentrantLock 的 tryLock，就能主动退出、释放、重试，把死锁风险转为可恢复的失败。
- 绝不连续调用 lock.lock() —— 第二把锁失败时，第一把已占却无法推进，反而加剧资源独占
- 每把锁都用 tryLock(200, TimeUnit.MILLISECONDS)，任一失败立即 unlock 已获锁
- 重试时加入随机退避（如 10–100ms），避免多线程同步撞车，制造新热点
- 超时不是万能，但它是最后一道防线：让问题从“卡死”变成“可感知、可降级、可重试”
缩小锁粒度与解耦边界（减少冲突面）
很多所谓“死锁”，本质是锁得太粗、太久、太盲目。把大锁拆小、把同步移出、把读写分离，冲突概率自然下降。
立即学习“Java免费学习笔记（深入）”；
- 把长临界区拆成多个短块，中间插入非同步逻辑（如日志、计算、校验），降低多锁共持时间
- 读多写少场景优先用 ConcurrentHashMap、CopyOnWriteArrayList 或 ReentrantReadWriteLock
- 绝对禁止在 synchronized 块内调用外部方法——尤其 RPC、DB 查询、回调函数，它们可能暗中引入未知锁
- 计数类操作改用 LongAdder，避免 synchronized ++ 这种低效且易争抢的写法
死锁排查与定位（线上可用手段）
预防再好也难保万无一失，关键是要能在问题发生时快速确认、精准还原、及时止损。
- jstack <pid> 直接输出线程堆栈，搜索 “Found one Java-level deadlock” 即可定位闭环线程及所持锁
- JConsole 启动后进入“Threads”页签，点“Detect Deadlock”，JVM 自动扫描并高亮显示死锁线程
- 代码中集成 ThreadMXBean.findDeadlockedThreads()，配合定时任务+告警，实现运行时主动探测
- 关键锁操作附近打结构化日志，如 “acquiring order-lock-12345 on behalf of user-67890”，便于事后串联加锁序列验证是否守序
