什么情况下Java程序会产生死锁？

最新推荐文章于 2025-09-14 13:57:05 发布

转载最新推荐文章于 2025-09-14 13:57:05 发布 · 3.2k 阅读

Java编程面试专栏收录该内容

30 篇文章

订阅专栏

本文详细解释了死锁的概念及发生原理，展示了如何通过jstack等工具定位死锁，并提供了几种预防死锁的有效方法。

典型回答

死锁是一种特定的程序状态，在实体之间，由于循环依赖导致彼此一直处于等待之中，没有任何个体可以继续前进。死锁不仅仅会发生在线程之间，存在资源独占的进程之间同样也可能出现死锁。通常来说，我们大多是聚焦在多线程场景中的死锁，指两个或多个线程之间，由于互相持有对方需要的锁，而永久处于阻塞的状态。

就像下图中所示：

定位死锁最常见的方式就是利用jstack等工具获取线程栈，然后定位互相之间的依赖关系，进而找到死锁。如果是比较明显的死锁，往往jstack等就能直接定位，类似JConsole甚至可以在图形界面进行有限的死锁检测。

如果程序运行时发生了死锁，绝大多数情况下都是无法在线解决的，只能重启、修正程序本身问题。所以，代码开发阶段互相审查，或者利用工具进行预防性排查，往往也是很重要的。

知识扩展

下面这个程序，只用了两个嵌套的synchronized去获取锁，几乎每次都可以重现死锁：

public class DeadLockSample extends Thread {
  private String first;
  private String second;
  public DeadLockSample(String name, String first, String second) {
    super(name);
    this.first = first;
    this.second = second;
  }

  public void run() {
    synchronized (first) {
      System.out.println(this.getName() + " obtained: " + first);
      try {
        Thread.sleep(1000L);
        synchronized (second) {
          System.out.println(this.getName() + " obtained: " + second);
        }
      } catch (InterruptedException e) {
        // Do Nothing
      }
    }
  }

  public static void main(String[] args) throws InterruptedException {
    String lockA = "lockA";
    String lockB = "lockB";
    DeadLockSample t1 = new DeadLockSample("Thread1", lockA, lockB);
    DeadLockSample t2 = new DeadLockSample("Thread2", lockB, lockA);
    t1.start();
    t2.start();
    t1.join();
    t2.join();
  }
}

某一次的输出如下：

Thread2 obtained: lockB
Thread1 obtained: lockA

这里有个比较有意思的地方，为什么先调用Thread1的start，但是Thread2却先打印出来了呢？这就是因为线程调度依赖于操作系统调度器。虽然你可以通过优先级之类进行影响，但是具体情况是不确定的。

下面来模拟问题定位，这里就选取最常见的jstack。首先，可以使用jps或者系统的ps命令、任务管理器等工具，确定进程ID。第二步，调用jstack获取线程栈：

>jstack your-pid

然后，分析得到的输出，具体片段如下：

Java stack information for the threads listed above:
===================================================
"Thread2":
        at cn.liximing.study.javacore.DeadLockSample.run(DeadLockSample.java:23)
        - waiting to lock <0x000000078097aea0> (a java.lang.String)
        - locked <0x000000078097aed8> (a java.lang.String)
"Thread1":
        at cn.liximing.study.javacore.DeadLockSample.run(DeadLockSample.java:23)
        - waiting to lock <0x000000078097aed8> (a java.lang.String)
        - locked <0x000000078097aea0> (a java.lang.String)

Found 1 deadlock.

上面的输出可以看出，jstack本身也会把类似的简单死锁抽取出来，直接打印出来。但是一些复杂的情况，则需要分析各个线程持有的锁，以及等待的锁进行分析。

如何在编程中尽量预防死锁？

首先，我们来总结一下前面例子中死锁的产生包含了哪些基本元素。基本上死锁的发生是因为：

互斥条件，类似Java中Monitor都是独占的，要么是我用，要么是你用。
互斥条件是长期持有的，在使用结束之前，自己不会释放，也不能被其它线程抢占。
循环依赖关系，两个或者多个个体之间出现了锁的链条环。

据此分析得到以下一些避免死锁的思路和方法。

方法一：如果可能的话，尽量避免使用多个锁，并且只有需要时才持有锁。

程序之所以需要持有多个锁，就是因为需要持有多个资源。从程序设计的角度反思，如果我们赋予一段程序太多的职责，出现“既要……又要……”的情况时，可能就需要我们审视下设计思路或目的是否合理了。

方法二：如果必须使用多个锁，尽量设计好锁的获取顺序。

这个说起来简单，做起来可不容易，你可以参考著名的“银行家算法”。一般的情况，建议可以采取一些简单的辅助手段。比如：将对象（方法）和锁之间的关系，用图形化的方式分别抽取出来。然后根据对象之间组合、调用的关系对比和组合，考虑可能调用的时序。按照可能时序合并，发现可能死锁的场景。

方法三：使用带超时的方法，为程序带来更多可控性。

类似Object.wait(...)或者CountDownLatch.await(...)，都支持所谓的timed_wait，我们完全可以不假定该锁一定会获得，指定超时时间，并为无法得到锁时准备退出逻辑。

并发Lock实现，如ReentrantLock还支持非阻塞式的获取锁操作tryLock()，这是一个插队行为（barging），并不在乎等待的公平性。如果执行时对象恰好没有被独占，则直接获取锁。有时，我们希望条件允许就尝试插队，不然就按照现有公平性规则等待，一般采用下面的方法：

if (lock.tryLock() || lock.tryLock(timeout, unit)) {
  // ...
}

方法四：通过静态代码分析工具去查找固定模式。

业界也有一些其它方面的尝试，比如通过静态代码分析（如FindBugs）去查找固定的模式，进而定位可能的死锁或者竞争情况。实践证明这种方法也有一定的作用。

【完】