关于死锁以及如何查看线程是否有死锁

最新推荐文章于 2024-03-13 19:43:49 发布

Objectobj

最新推荐文章于 2024-03-13 19:43:49 发布

阅读量1.8k

点赞数 1

文章标签：多线程 java

本文链接：https://blog.csdn.net/Objectobj/article/details/105505382

版权

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

什么是死锁？

package cn.sxt.game;
/* 死锁
*
* */
public class DeadLock {
    public static void main(String[] args) {
        Object o1=new Object();
        Object o2=new Object();
        Thread t1=new MyThread1(o1,o2);
        Thread t2=new MyThread2(o1,o2);
        t1.setName("t1");//给线程起名字t1
        t2.setName("t2");//给线程起名字t2
        t1.start();
        t2.start();
    }
}
class MyThread1 extends Thread{
    Object o1;
    Object o2;
    public MyThread1(Object o1,Object o2){
        this.o1=o1;
        this.o2=o2;
    }

    @Override
    public void run() {
        synchronized (o1){
            try {
                System.out.println("获取资源1");
                sleep(1000);// 等待 1 秒让另一个线程拿到锁
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (o2){

            }
        }
    }
}
class MyThread2 extends Thread{
    Object o1;
    Object o2;
    public MyThread2(Object o1,Object o2){
        this.o1=o1;
        this.o2=o2;
    }

    @Override
    public void run() {
        synchronized (o2){
            try {
                System.out.println("获取资源2");
                sleep(1000);// 等待 1 秒让另一个线程拿到锁
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (o1){

            }
        }
    }
}

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

这种情况就是死锁。

像我们现在写的代码是自己故意造出来的死锁，我们能够发现，那如果是线上环境怎么办，假如我们的系统卡死了，我们怎么知道到底是哪一段代码出现了问题，有没有可能使死锁的问题。也就是如何检测死锁。
2. 如何检测死锁？
由于死锁极难通过人工的方式查出来，因此JDK 提供了命令来检测某个java进程中心线程的情况，并排查有没有死锁。 jps , 用来查看java 程序的进程号，当然在 Linux 中也可以通过别的方式获取， jstack 进程号命令则可以答应对应进程的栈信息，并找到死锁。
在windows使用jps的命令

C:\Users\16047>jps
        1488 Jps
        3028 Launcher
        9188 DeadLock
        2632

        C:\Users\16047>jstack 9188
        2020-04-14 09:05:35
        Full thread dump Java HotSpot(TM) 64-Bit Server VM (13.0.1+9 mixed mode, sharing):

        Threads class SMR info:
        _java_thread_list=0x00000254ffd7b290, length=13, elements={
        0x00000254ffa11000, 0x00000254ffa14800, 0x00000254ffa37000, 0x00000254ffa38000,
        0x00000254ffa39800, 0x00000254ffae1000, 0x00000254ffa42800, 0x00000254ff9f5800,
        0x00000254ffced800, 0x00000254ffcf7000, 0x00000254ffd04800, 0x00000254ffd3f800,
        0x00000254f8011800
        }

        "Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms elapsed=108.48s tid=0x00000254ffa11000 nid=0x28e4 waiting on condition  [0x00000065b3afe000]
        java.lang.Thread.State: RUNNABLE
        at java.lang.ref.Reference.waitForReferencePendingList(java.base@13.0.1/Native Method)
        at java.lang.ref.Reference.processPendingReferences(java.base@13.0.1/Reference.java:241)
        at java.lang.ref.Reference$ReferenceHandler.run(java.base@13.0.1/Reference.java:213)

        "Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=108.48s tid=0x00000254ffa14800 nid=0x4204 in Object.wait()  [0x00000065b3bfe000]
        java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@13.0.1/Native Method)
        - waiting on <0x0000000089d0aec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@13.0.1/ReferenceQueue.java:155)
        - locked <0x0000000089d0aec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@13.0.1/ReferenceQueue.java:176)
        at java.lang.ref.Finalizer$FinalizerThread.run(java.base@13.0.1/Finalizer.java:170)

        "Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=108.46s tid=0x00000254ffa37000 nid=0x181c runnable  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE

        "Attach Listener" #5 daemon prio=5 os_prio=2 cpu=31.25ms elapsed=108.46s tid=0x00000254ffa38000 nid=0x2bb4 waiting on condition  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE

        "C2 CompilerThread0" #6 daemon prio=9 os_prio=2 cpu=62.50ms elapsed=108.46s tid=0x00000254ffa39800 nid=0x25c0 waiting on condition  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE
        No compile task

        "C1 CompilerThread0" #9 daemon prio=9 os_prio=2 cpu=46.88ms elapsed=108.46s tid=0x00000254ffae1000 nid=0x2988 waiting on condition  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE
        No compile task

        "Sweeper thread" #10 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=108.46s tid=0x00000254ffa42800 nid=0x3ce8 runnable  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE

        "Common-Cleaner" #11 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=108.44s tid=0x00000254ff9f5800 nid=0x3b78 in Object.wait()  [0x00000065b41fe000]
        java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(java.base@13.0.1/Native Method)
        - waiting on <0x0000000089db21c0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@13.0.1/ReferenceQueue.java:155)
        - locked <0x0000000089db21c0> (a java.lang.ref.ReferenceQueue$Lock)
        at jdk.internal.ref.CleanerImpl.run(java.base@13.0.1/CleanerImpl.java:148)
        at java.lang.Thread.run(java.base@13.0.1/Thread.java:830)
        at jdk.internal.misc.InnocuousThread.run(java.base@13.0.1/InnocuousThread.java:134)

        "Monitor Ctrl-Break" #12 daemon prio=5 os_prio=0 cpu=15.63ms elapsed=108.36s tid=0x00000254ffced800 nid=0x2a38 runnable  [0x00000065b43fe000]
        java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.SocketDispatcher.read0(java.base@13.0.1/Native Method)
        at sun.nio.ch.SocketDispatcher.read(java.base@13.0.1/SocketDispatcher.java:46)
        at sun.nio.ch.NioSocketImpl.tryRead(java.base@13.0.1/NioSocketImpl.java:262)
        at sun.nio.ch.NioSocketImpl.implRead(java.base@13.0.1/NioSocketImpl.java:313)
        at sun.nio.ch.NioSocketImpl.read(java.base@13.0.1/NioSocketImpl.java:351)
        at sun.nio.ch.NioSocketImpl$1.read(java.base@13.0.1/NioSocketImpl.java:802)
        at java.net.Socket$SocketInputStream.read(java.base@13.0.1/Socket.java:937)
        at sun.nio.cs.StreamDecoder.readBytes(java.base@13.0.1/StreamDecoder.java:297)
        at sun.nio.cs.StreamDecoder.implRead(java.base@13.0.1/StreamDecoder.java:339)
        at sun.nio.cs.StreamDecoder.read(java.base@13.0.1/StreamDecoder.java:188)
        - locked <0x0000000089b125a0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(java.base@13.0.1/InputStreamReader.java:185)
        at java.io.BufferedReader.fill(java.base@13.0.1/BufferedReader.java:161)
        at java.io.BufferedReader.readLine(java.base@13.0.1/BufferedReader.java:326)
        - locked <0x0000000089b125a0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(java.base@13.0.1/BufferedReader.java:392)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

        "Service Thread" #13 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=108.36s tid=0x00000254ffcf7000 nid=0x42b4 runnable  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE

        "t1" #14 prio=5 os_prio=0 cpu=0.00ms elapsed=108.35s tid=0x00000254ffd04800 nid=0x3384 waiting for monitor entry  [0x00000065b46fe000]
        java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.sxt.game.MyThread1.run(DeadLock.java:36)
        - waiting to lock <0x0000000089ccb560> (a java.lang.Object)
        - locked <0x0000000089ccb550> (a java.lang.Object)

        "t2" #15 prio=5 os_prio=0 cpu=0.00ms elapsed=108.35s tid=0x00000254ffd3f800 nid=0x3c18 waiting for monitor entry  [0x00000065b47ff000]
        java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.sxt.game.MyThread2.run(DeadLock.java:59)
        - waiting to lock <0x0000000089ccb550> (a java.lang.Object)
        - locked <0x0000000089ccb560> (a java.lang.Object)

        "DestroyJavaVM" #16 prio=5 os_prio=0 cpu=156.25ms elapsed=108.35s tid=0x00000254f8011800 nid=0x2780 waiting on condition  [0x0000000000000000]
        java.lang.Thread.State: RUNNABLE

        "VM Thread" os_prio=2 cpu=0.00ms elapsed=108.48s tid=0x00000254ffa10000 nid=0x2544 runnable

        "GC Thread#0" os_prio=2 cpu=0.00ms elapsed=108.49s tid=0x00000254f8055800 nid=0x117c runnable

        "G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=108.49s tid=0x00000254f8066800 nid=0x3098 runnable

        "G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=108.49s tid=0x00000254f8068800 nid=0x24e4 runnable

        "G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=108.49s tid=0x00000254ff88a800 nid=0x127c runnable

        "G1 Young RemSet Sampling" os_prio=2 cpu=0.00ms elapsed=108.49s tid=0x00000254ff88c000 nid=0x1900 runnable
        "VM Periodic Task Thread" os_prio=2 cpu=0.00ms elapsed=108.36s tid=0x00000254ffcfa800 nid=0x230c waiting on condition

        JNI global refs: 16, weak refs: 0

        // 找到一个死锁
        Found one Java-level deadlock:
        =============================
        "t1":
        waiting to lock monitor 0x00000254ffa1df00 (object 0x0000000089ccb560, a java.lang.Object),
        which is held by "t2"
        "t2":
        waiting to lock monitor 0x00000254ffa1dd00 (object 0x0000000089ccb550, a java.lang.Object),
        which is held by "t1"

        Java stack information for the threads listed above:
        ===================================================
        "t1":
        at cn.sxt.game.MyThread1.run(DeadLock.java:36)
        // 等待 0x0000000089ccb560 锁
        - waiting to lock <0x0000000089ccb560> (a java.lang.Object)
        //持有0x0000000089ccb550 锁
        - locked <0x0000000089ccb550> (a java.lang.Object)
        "t2":
        at cn.sxt.game.MyThread2.run(DeadLock.java:59)
        //等待0x0000000089ccb550 锁
        - waiting to lock <0x0000000089ccb550> (a java.lang.Object)
        // 持有 0x0000000089ccb560 锁
        - locked <0x0000000089ccb560> (a java.lang.Object)
        //发现一个死锁
        Found 1 deadlock.

t1  waiting to lock <0x0000000089ccb560>locked <0x0000000089ccb550>
t2  waiting to lock <0x0000000089ccb550>locked <0x0000000089ccb560>

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

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

死锁有哪些形成的原因
一般来说，要出现死锁问题需要满足以下条件：

互斥条件：一个资源每次只能被一个线程使用。

请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

不剥夺条件：进程已获得的资源，在未使用完之前，不能强行剥夺。

循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

死锁是由四个必要条件导致的，所以一般来说，只要破坏这四个必要条件中的一个条件，死锁情况就应该不会发生。
我们在编程的时候尽量避免发生死锁，如果出现死锁可以使用 jstack 命令查看线程是否有死锁。

Objectobj

关注

1
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
关于死锁以及如何查看线程是否有死锁

在 Java 的并发编程中，有一个问题需要特别注意，那就是死锁，如果发生了死锁，基本就是重启，而重启将会丢失运行中的数据。所以，了解死锁的形成并排查死锁到预防死锁成了一个重要的问题。什么是死锁？package cn.sxt.game;/* 死锁** */public class DeadLock { public static void main(String[] args...
复制链接

扫一扫