死锁发生时，Thread.dumpStack() 和 jstack 能看到什么
线程卡住不动、CPU 低、请求堆积，但日志没报错——这时候大概率是死锁。Java 自身会检测到部分循环等待并自动记录，但只限于「互相持有对方需要的锁」这种经典场景。jstack <pid> 输出里如果出现 Found 1 deadlock.，下面跟着的线程栈就是关键证据：你会看到两个（或多个）Thread 都停在 Object.wait() 或 Unsafe.park()，且各自持有一个锁、又在等另一个锁。
注意：Thread.dumpStack() 不会帮你发现死锁，它只打印当前线程调用栈，不分析锁关系；真正有用的是 jstack -l <pid>（加 -l 才显示锁信息）。
- 生产环境别等用户反馈才查，建议定期采集
jstack快照，尤其在压测后 - Spring Boot 应用可暴露
/actuator/threaddump端点，返回的就是jstack格式内容 - 如果
jstack没标出 deadlock，但线程明显卡住，可能是自旋锁、I/O 阻塞或ReentrantLock.tryLock()无限重试，不是 JVM 认定的“死锁”
synchronized 嵌套和 ReentrantLock 顺序不一致是高频雷区
最常见死锁模式：线程 A 先锁 accountA 再锁 accountB，线程 B 反过来先锁 accountB 再锁 accountA。只要调度稍有交错，就卡死。问题不在锁本身，而在「获取顺序没约定」。
解决方法不是少用锁，而是统一顺序：
立即学习“Java免费学习笔记（深入）”；
- 对锁对象做自然排序，比如按
account.getId()升序决定加锁次序，两个线程都必须先锁 ID 小的再锁大的 - 避免在同步块里调用外部方法——万一那个方法内部又去抢另一把锁，你根本控制不了顺序
-
ReentrantLock的tryLock(long, TimeUnit)可设超时，抢不到就释放已持锁并重试，比无脑lock()安全得多
示例：用 ID 排序避免嵌套死锁
long id1 = accountA.getId();
long id2 = accountB.getId();
if (id1 < id2) {
synchronized (accountA) {
synchronized (accountB) { /* transfer */ }
}
} else {
synchronized (accountB) {
synchronized (accountA) { /* transfer */ }
}
}数据库行锁 + JVM 锁混合使用时，顺序错位直接触发分布式死锁
Java 层用 synchronized 控制账户余额变更，同时 SQL 用 SELECT ... FOR UPDATE 锁行——这两层锁的加锁顺序若不一致，死锁概率陡增。比如 Java 层按 user_id 排序加锁，而数据库因索引或执行计划，实际按 order_id 顺序加锁，JVM 和 MySQL 各自按自己逻辑走，结果就是「Java 线程 A 持 JVM 锁等 DB 锁，线程 B 持 DB 锁等 JVM 锁」。
- 优先让数据库承担串行化责任：用唯一业务键（如
user_id）做FOR UPDATE的 where 条件，并确保该字段有索引，避免锁升级成表锁 - Java 层锁粒度尽量与 DB 一致，比如用
userId作同步对象，而不是 new 出来的临时对象 - MySQL 的
innodb_lock_wait_timeout默认 50 秒，远长于多数业务接口超时，会导致死锁被掩盖成“慢请求”，建议调低到 5–10 秒并捕获DeadlockLoserDataAccessException
用 java.util.concurrent.locks.LockSupport 自定义同步逻辑极易误用
LockSupport.park() 和 unpark() 是底层工具，不带锁语义、不检查线程状态、也不记录所有权。写错一两个 unpark() 调用位置，就可能让某个线程永远 park 在那里，表面看像死锁，实则是资源信号丢失。
- 不要把它当
synchronized替代品；它适合实现 AQS、自旋锁等，普通业务代码几乎用不到 -
park()前没对应unpark()，线程就挂起不返；unpark()提前调了，后续park()会直接返回，导致状态判断错乱 - 调试时用
Thread.getState() == WAITING或parking判断是否卡住，但无法反推谁该 unpark 它——这正是它难排查的原因
事情说清了就结束。死锁不是“有没有锁”的问题，是“谁在什么时候以什么顺序拿哪些锁”的问题。越想绕开锁，越容易掉进更隐蔽的坑里。
