Java死锁原因及解决方法详解

文章不知道大家是否熟悉？今天我将给大家介绍《Java死锁问题详解及成因分析》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

死锁是多个线程因循环等待对方持有的锁而永久阻塞的状态，需同时满足互斥、请求与保持、不可剥夺、循环等待四个条件；典型场景如银行转账中加锁顺序不一致；synchronized可重入故同线程内不会死锁。

死锁是指两个或多个线程在执行过程中，因互相等待对方持有的锁而陷入永久阻塞的状态。此时所有相关线程都无法继续推进，程序逻辑停滞，资源也无法释放。

死锁的四个必要条件

只有当以下四个条件同时满足时，死锁才可能发生：

• 互斥条件：一个资源（如对象锁）同一时刻只能被一个线程持有。例如用 synchronized 或 ReentrantLock 加锁时，其他线程必须等待。
• 请求与保持：线程已持有至少一把锁，又去申请另一把锁，且不释放已有锁。比如先锁 A 再尝试锁 B，但 B 已被别的线程占用。
• 不可剥夺：线程持有的锁不能被系统强制收回，只能由该线程主动释放。Java 中没有提供“强行解锁”机制，因此这一条件天然成立。
• 循环等待：存在线程链 A→B→C→A，每个线程都在等下一个线程持有的锁。最常见的是两个线程相互等待：线程1持 lock1 等 lock2，线程2持 lock2 等 lock1。

典型死锁场景还原

银行转账是经典例子：账户 A 向 B 转账时，按 sync(A) → sync(B) 顺序加锁；而 B 向 A 转账时，却按 sync(B) → sync(A) 顺序加锁。一旦两个操作并发发生，就极易触发循环等待。

另一个常见误写是嵌套同步块中锁对象顺序不一致，或在不同方法中对同一组资源采用不同加锁次序。

为什么 synchronized 不会因重入导致死锁

同一个线程对同一个对象重复加 synchronized 锁不会死锁，因为它是可重入锁。JVM 内部记录了持有者线程和重入次数，再次进入时仅计数+1，无需等待。但这只适用于单线程内重入，跨线程竞争仍可能死锁。

检测与定位手段

运行时可通过 JDK 工具快速识别：

• 用 jps 查出 Java 进程 PID；
• 用 jstack 输出线程栈；
• 关注输出中是否含 "Found one Java-level deadlock" 提示，以及线程状态为 waiting to lock 且彼此指向对方锁对象。

到这里，我们也就讲完了《Java死锁原因及解决方法详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！