并发编程之死锁解析

怼烎@ 2021-12-15 22:27 344阅读 0赞

转载

前言

在 Java 的并发编程中，有一个问题需要特别注意，那就是死锁，如果发生了死锁，基本就是重启，而重启将会丢失运行中的数据。所以，了解死锁的形成并排查死锁到预防死锁成了一个重要的问题。

我们了解任何一个事情的步骤是：what，how，why，why not。

1. 什么是死锁？

我们还是直接写一段代码来看看：

  1. package hello;
  3. public class DeadLock {
  5.   public static void main(String[] args) {
  7.     new Thread(() -> {
  8.       try {
  9.          new DeadLock().resource1();
  10.       } catch (InterruptedException e) {
  11.       }
  12.     }
  13.     ).start();
  15.     new Thread(() -> {
  16.       try {
  17.          new DeadLock().resource2();
  18.       } catch (InterruptedException e) {
  19.       }
  20.     }
  21.     ).start();
  22.   }
  24.   void resource1() throws InterruptedException {
  26.     synchronized ("resource1") {
  27.       System.out.println("获取资源1");
  28.        // 等待 1 秒让另一个线程拿到锁
  29.       Thread.sleep(1000);
  30.       resource2();
  31.     }
  34.   }
  36.   void resource2() throws InterruptedException {
  37.     synchronized ("resource2") {
  38.       System.out.println("获取资源2");
  39.       // 等待 1 秒让另一个线程拿到锁
  40.       Thread.sleep(1000);
  41.       resource1();
  42.     }
  43.   }
  44. }

上面的代码中，我们启用了两个线程，分别抢占2个资源，但这两个资源又分别被不同的对象（字符串）锁住了。当第一个线程调用 resource1 方法，进入同步块，拿到锁，并等待 1 秒钟让另一个线程进入 resource2 同步块，当第二个线程进入同步块后，注意：此时， 拿着 resourec1 锁的线程企图拿到 resource2 的锁，但这个时候，拿着 resource2 的线程也想去拿 resource1 的锁。于是就出现了互相僵持的情况，谁也无法拿到对方的锁，整个系统就卡死了。

这种情况就是死锁。

像我们现在写的代码是自己故意造出来的死锁，我们能够发现，那如果是线上环境怎么办，假如我们的系统卡死了，我们怎么知道到底是哪一段代码出现了问题，有没有可能使死锁的问题。也就是如何检测死锁。

2. 如何检测死锁？

由于死锁极难通过人工的方式查出来，因此JDK 提供了命令来检测某个java进程中心线程的情况，并排查有没有死锁。上面命令呢？ jps , 用来查看java 程序的进程号，当然在 Linux 中也可以通过别的方式获取， jstack 进程号命令则可以答应对应进程的栈信息，并找到死锁。

我们就刚刚的程序，在 windows 上使用该命令。

  1. C:\Users\stateis0>jps
  2. 11060
  3. 2084 Launcher
  4. 10712 RemoteMavenServer
  5. 18040 Jps
  6. 11820 DeadLock
  12. C:\Users\stateis0>jstack 11820
  13. 2017-12-29 18:52:38
  14. Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode):
  16. "DestroyJavaVM" #11 prio=5 os_prio=0 tid=0x051fe800 nid=0x1e0c waiting on condition [0x00000000]
  17.    java.lang.Thread.State: RUNNABLE
  19. "Thread-1" #10 prio=5 os_prio=0 tid=0x18777800 nid=0x5664 waiting for monitor entry [0x18e0f000]
  20.    java.lang.Thread.State: BLOCKED (on object monitor)
  21.         at hello.DeadLock.resource1(DeadLock.java:31)
  22.         - waiting to lock <0x07415a50> (a java.lang.String)
  23.         at hello.DeadLock.resource2(DeadLock.java:43)
  24.         - locked <0x0742bd18> (a java.lang.String)
  25.         at hello.DeadLock.lambda$main$1(DeadLock.java:20)
  26.         at hello.DeadLock$$Lambda$2/4983748.run(Unknown Source)
  27.         at java.lang.Thread.run(Thread.java:748)
  29. "Thread-0" #9 prio=5 os_prio=0 tid=0x18776c00 nid=0x4dc4 waiting for monitor entry [0x18d7f000]
  30.    java.lang.Thread.State: BLOCKED (on object monitor)
  31.         at hello.DeadLock.resource2(DeadLock.java:41)
  32.         - waiting to lock <0x0742bd18> (a java.lang.String)
  33.         at hello.DeadLock.resource1(DeadLock.java:33)
  34.         - locked <0x07415a50> (a java.lang.String)
  35.         at hello.DeadLock.lambda$main$0(DeadLock.java:11)
  36.         at hello.DeadLock$$Lambda$1/5592464.run(Unknown Source)
  37.         at java.lang.Thread.run(Thread.java:748)
  39. "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x186e4c00 nid=0x172c runnable [0x00000000]
  40.    java.lang.Thread.State: RUNNABLE
  42. "C1 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x186af000 nid=0x53f8 waiting on condition [0x00000000]
  43.    java.lang.Thread.State: RUNNABLE
  45. "Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x1861e800 nid=0x3928 runnable [0x18b3f000]
  46.    java.lang.Thread.State: RUNNABLE
  47.         at java.net.SocketInputStream.socketRead0(Native Method)
  48.         at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
  49.         at java.net.SocketInputStream.read(SocketInputStream.java:171)
  50.         at java.net.SocketInputStream.read(SocketInputStream.java:141)
  51.         at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
  52.         at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
  53.         at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
  54.         - locked <0x07861da0> (a java.io.InputStreamReader)
  55.         at java.io.InputStreamReader.read(InputStreamReader.java:184)
  56.         at java.io.BufferedReader.fill(BufferedReader.java:161)
  57.         at java.io.BufferedReader.readLine(BufferedReader.java:324)
  58.         - locked <0x07861da0> (a java.io.InputStreamReader)
  59.         at java.io.BufferedReader.readLine(BufferedReader.java:389)
  60.         at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)
  62. "Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x179c0800 nid=0x40a0 waiting on condition [0x00000000]
  63.    java.lang.Thread.State: RUNNABLE
  65. "Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x17985c00 nid=0x5004 runnable [0x00000000]
  66.    java.lang.Thread.State: RUNNABLE
  68. "Finalizer" #3 daemon prio=8 os_prio=1 tid=0x17972400 nid=0x41a8 in Object.wait() [0x17cff000]
  69.    java.lang.Thread.State: WAITING (on object monitor)
  70.         at java.lang.Object.wait(Native Method)
  71.         - waiting on <0x0ca1b830> (a java.lang.ref.ReferenceQueue$Lock)
  72.         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
  73.         - locked <0x0ca1b830> (a java.lang.ref.ReferenceQueue$Lock)
  74.         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
  75.         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
  77. "Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x17960000 nid=0x4ef0 in Object.wait() [0x17c6f000]
  78.    java.lang.Thread.State: WAITING (on object monitor)
  79.         at java.lang.Object.wait(Native Method)
  80.         - waiting on <0x0ca1b9d0> (a java.lang.ref.Reference$Lock)
  81.         at java.lang.Object.wait(Object.java:502)
  82.         at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
  83.         - locked <0x0ca1b9d0> (a java.lang.ref.Reference$Lock)
  84.         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
  86. "VM Thread" os_prio=2 tid=0x1795a800 nid=0x3f54 runnable
  88. "VM Periodic Task Thread" os_prio=2 tid=0x18739400 nid=0x4a14 waiting on condition
  90. JNI global references: 229
  92. // 找到一个死锁
  93. Found one Java-level deadlock:
  94. =============================
  95. "Thread-1":
  96.   waiting to lock monitor 0x17978de4 (object 0x07415a50, a java.lang.String),
  97.   which is held by "Thread-0"
  98. "Thread-0":
  99.   waiting to lock monitor 0x1797a974 (object 0x0742bd18, a java.lang.String),
  100.   which is held by "Thread-1"
  102. Java stack information for the threads listed above:
  103. ===================================================
  104. "Thread-1":
  105.         at hello.DeadLock.resource1(DeadLock.java:31)
  106.          // 等待 0x07415a50 锁
  107.         - waiting to lock <0x07415a50> (a java.lang.String)
  108.         at hello.DeadLock.resource2(DeadLock.java:43)
  109.         // 持有 0x0742bd18
  110.         - locked <0x0742bd18> (a java.lang.String)
  111.         at hello.DeadLock.lambda$main$1(DeadLock.java:20)
  112.         at hello.DeadLock$$Lambda$2/4983748.run(Unknown Source)
  113.         at java.lang.Thread.run(Thread.java:748)
  114. "Thread-0":
  115.         at hello.DeadLock.resource2(DeadLock.java:41)
  116.         // 等待 0x0742bd18 锁
  117.         - waiting to lock <0x0742bd18> (a java.lang.String)
  118.         at hello.DeadLock.resource1(DeadLock.java:33)
  119.         // 持有 0x07415a50
  120.         - locked <0x07415a50> (a java.lang.String)
  121.         at hello.DeadLock.lambda$main$0(DeadLock.java:11)
  122.         at hello.DeadLock$$Lambda$1/5592464.run(Unknown Source)
  123.         at java.lang.Thread.run(Thread.java:748)
  125. // 发现了一个死锁
  126. Found 1 deadlock.
  128. C:\Users\stateis0>

Thread-1 waiting to lock <0x07415a50> locked <0x0742bd18> Thread-0 waiting to lock <0x0742bd18> locked <0x07415a50>

我们首先使用 jps 命令找到 java 进程号，然后使用 jstack 进程号 打印进程栈的信息，其中，在最后的部分，jstack 告诉我们，他找到了一个死锁，其中又详细的信息：Thread-1 线程（这里我们没有给线程其合适的名字，如果在线上，给线程起一个合适的名字将更有利于排查）持有 String 类型的编号为 0x07415a50 的锁，等待编号为 0x07415a50 的锁 ， 但这个锁由 Thread-0 持有，于此同时，Thread-0 和 Thread-1 相反。Thread-0 线程持有 0x07415a50 的锁，等待 0x07415a50 的锁。我们的注释里也写上了。

那么发生了死锁，该怎么办呢？最简单的办法就是重启，重启之后，对 jstack 中打印的堆栈信息中的代码进行修改。重新发布。当然还有一些高级策略，比如让进程回滚到死锁前的状态，然后让他们顺序进入同步块。

3. 死锁有哪些形成的原因

一般来说，要出现死锁问题需要满足以下条件：

互斥条件：一个资源每次只能被一个线程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件：进程已获得的资源，在未使用完之前，不能强行剥夺。
循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。
死锁是由四个必要条件导致的，所以一般来说，只要破坏这四个必要条件中的一个条件，死锁情况就应该不会发生。

如果想要打破互斥条件，我们需要允许进程同时访问某些资源，这种方法受制于实际场景，不太容易实现条件；

打破不可抢占条件，这样需要允许进程强行从占有者那里夺取某些资源，或者简单一点理解，占有资源的进程不能再申请占有其他资源，必须释放手上的资源之后才能发起申请，这个其实也很难找到适用场景；

进程在运行前申请得到所有的资源，否则该进程不能进入准备执行状态。这个方法看似有点用处，但是它的缺点是可能导致资源利用率和进程并发性降低；

避免出现资源申请环路，即对资源事先分类编号，按号分配。这种方式可以有效提高资源的利用率和系统吞吐量，但是增加了系统开销，增大了进程对资源的占用时间。

4. 总结

并发编程中的坑很多，尤其死锁，造成的问题基本只能靠重启来解决，如果遇到了数据保存在内存中但没有持久化的话，那么重启将出现很大的问题。因此我们在用锁的时候，一定要小心。避免出现死锁，如果出现了死锁，则可以使用 jstack 命令查看线程是否有死锁。用以排查问题。

总之并发的坑很多，楼主以后将会多多分析。

发表评论

表情：
评论列表 （有 0 条评论，344人围观）

还没有评论，来说两句吧...

相关阅读

    相关 Java并发编程：死锁实例解析

    在Java并发编程中，死锁是一个常见的问题。死锁是指两个或更多的进程（线程）因争夺资源而造成的一种互相等待的现象，若无外力干涉它们将无法继续执行。 以下是一例简单的Java死

    小咪咪小咪咪/ 0 赞/ 115 阅读

    相关 Java并发编程：死锁现象解析

    在Java的并发编程中，死锁是一种严重的状态，会导致资源无法继续使用。 死锁的现象通常有以下特征： 1. **互斥条件**：两个或多个线程正在访问并可能修改同一资源。 2

    男娘i男娘i/ 0 赞/ 165 阅读

    相关 Java并发编程：死锁案例解析

    在Java并发编程中，死锁是一个非常关键和常见的问题。简单来说，死锁是指两个或多个并发进程，在执行过程中因争夺资源而造成的一种互相等待的现象，且每个进程都处于等待状态，无法继续

    Bertha 。Bertha 。/ 0 赞/ 179 阅读

    相关 Java并发编程：死锁现象解析

    在Java并发编程中，死锁是一个非常关键且可能导致程序僵化的问题。 **什么是死锁？** 死锁是指两个或更多的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外

    亦凉亦凉/ 0 赞/ 175 阅读

    相关 并发编程之死锁解析

    [转载][Link 1] 前言 在 Java 的并发编程中，有一个问题需要特别注意，那就是死锁，如果发生了死锁，基本就是重启，而重启将会丢失运行中的数据。所以，了解死锁

    怼烎@怼烎@/ 0 赞/ 345 阅读