Java多线程死锁原因与解决方法

Java多线程死锁并非源于锁的使用本身，而是多个线程以不一致的顺序竞争同一组锁资源（如账户转账中A先锁accountA再锁accountB、B反之），导致循环等待；jstack -l 是定位经典死锁的关键利器，能清晰揭示线程持锁与等待锁的闭环关系，而Thread.dumpStack()则完全无能为力；真正有效的解决方案在于统一加锁顺序（如按ID自然排序）、避免同步块内调用不可控外部方法、合理使用tryLock超时机制、协同数据库行锁与JVM锁的一致性策略，并警惕LockSupport等底层工具误用引发的伪死锁——死锁的本质，永远是锁的获取时机与顺序失控，而非锁的存在。

死锁发生时，Thread.dumpStack() 和 jstack 能看到什么

线程卡住不动、CPU 低、请求堆积，但日志没报错——这时候大概率是死锁。Java 自身会检测到部分循环等待并自动记录，但只限于「互相持有对方需要的锁」这种经典场景。jstack 输出里如果出现 Found 1 deadlock.，下面跟着的线程栈就是关键证据：你会看到两个（或多个）Thread 都停在 Object.wait() 或 Unsafe.park()，且各自持有一个锁、又在等另一个锁。

注意：Thread.dumpStack() 不会帮你发现死锁，它只打印当前线程调用栈，不分析锁关系；真正有用的是 jstack -l （加 -l 才显示锁信息）。

• 生产环境别等用户反馈才查，建议定期采集 jstack 快照，尤其在压测后
• Spring Boot 应用可暴露 /actuator/threaddump 端点，返回的就是 jstack 格式内容
• 如果 jstack 没标出 deadlock，但线程明显卡住，可能是自旋锁、I/O 阻塞或 ReentrantLock.tryLock() 无限重试，不是 JVM 认定的“死锁”

synchronized 嵌套和 ReentrantLock 顺序不一致是高频雷区

最常见死锁模式：线程 A 先锁 accountA 再锁 accountB，线程 B 反过来先锁 accountB 再锁 accountA。只要调度稍有交错，就卡死。问题不在锁本身，而在「获取顺序没约定」。

解决方法不是少用锁，而是统一顺序：

• 对锁对象做自然排序，比如按 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 它——这正是它难排查的原因

事情说清了就结束。死锁不是“有没有锁”的问题，是“谁在什么时候以什么顺序拿哪些锁”的问题。越想绕开锁，越容易掉进更隐蔽的坑里。

好了，本文到此结束，带大家了解了《Java多线程死锁原因与解决方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！