Java之死锁定位分析

一路

已于 2022-10-11 15:18:40 修改

阅读量876

点赞数

分类专栏： JAVA 文章标签：多线程定位 java

于 2020-06-30 23:28:31 首次发布

本文链接：https://blog.csdn.net/li02112017/article/details/107052334

版权

JAVA 专栏收录该内容

28 篇文章 1 订阅

订阅专栏

什么是死锁

死锁是指多个进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力干涉那它们都将无法推进下去；如果资源充足，进程的资源请求都能得到满足，死锁出现的可能性就很低，否则将会因争夺有限的资源而陷入死锁；
在这里插入图片描述
产生死锁的主要原因：系统资源不足；进程运行推进的顺序不合适；资源分配不当；

形成死锁的四个必要条件：
（1）互斥条件：一个资源每次只能被一个进程使用。
（2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3）不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4）循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

死锁案例

编写一个死锁的Demo:

public class DeadLockDemo {

    public static void main(String[] args) {
        String lockA = "lockA";
        String lockB = "lockB";
        new Thread(new HoldLock(lockA,lockB)).start();
        new Thread(new HoldLock(lockB,lockA)).start();
    }
}

class HoldLock implements Runnable{
    private String lockA;
    private String lockB;

    public HoldLock(String lockA, String lockB) {
        this.lockA = lockA;
        this.lockB = lockB;
    }

    @Override
    public void run() {
        synchronized (lockA){
            System.out.println(Thread.currentThread().getName()+"---持有锁：" + lockA + "---试图获取锁："+lockB);
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (lockB){
                System.out.println(Thread.currentThread().getName()+"---持有锁：" + lockB);
            }
        }
    }
}

运行程序：
在这里插入图片描述

死锁定位分析

我们发现程序一直在运行，那我们需要怎么去判断及定位这个是由死锁导致的现象呢；
我们可以使用jps命令来进行查看运行的java应用程序；jps 命令类似与 linux 的 ps 命令，但是它只列出系统中所有的 Java 应用程序。通过 jps 命令可以方便地查看 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息。如果在 linux 中想查看 java 的进程，一般我们都需要 ps -ef | grep java 来获取进程 ID。如果只想获取 Java 程序的进程，可以直接使用 jps 命令来直接查看。
正常情况下，java自身一些应用如下图中所示：
在这里插入图片描述
运行上面编写的这个demo,我们可以看到这个demo的进程号为8264

我们在使用jstack 进程号命令查看堆栈信息；
jstack 8264 会打印如下信息：

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000002aae800 nid=0x3e8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001b2a6800 nid=0x3950 waiting for monitor entry [0x000000001bf2f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at lock.HoldLock.run(DeadLockDemo.java:38)
        - waiting to lock <0x0000000780991488> (a java.lang.String)
        - locked <0x00000007809914c0> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #11 prio=5 os_prio=0 tid=0x000000001b2a5800 nid=0x1968 waiting for monitor entry [0x000000001be2f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at lock.HoldLock.run(DeadLockDemo.java:38)
        - waiting to lock <0x00000007809914c0> (a java.lang.String)
        - locked <0x0000000780991488> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001b1eb000 nid=0xa94 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001b17a800 nid=0xf70 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x000000001b179000 nid=0x36d8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x000000001b177000 nid=0x197c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001b15f000 nid=0x1c18 runnable [0x000000001b82e000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x0000000780a2dae0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x0000000780a2dae0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000019df0000 nid=0x17ac waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000000019dda000 nid=0x17a4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000019dc9800 nid=0x1758 in Object.wait() [0x000000001b12f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000780808ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x0000000780808ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000002d34000 nid=0x3bb8 in Object.wait() [0x000000001b02f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000780806bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x0000000780806bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x0000000019da8000 nid=0x304c runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000002c58800 nid=0x2460 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000002c5a000 nid=0x1960 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000002c5b800 nid=0x1958 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002c5d800 nid=0xdec runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001b20d800 nid=0x1138 waiting on condition

JNI global references: 12


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x0000000002d3e648 (object 0x0000000780991488, a java.lang.String),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x0000000002d3d1a8 (object 0x00000007809914c0, a java.lang.String),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at lock.HoldLock.run(DeadLockDemo.java:38)
        - waiting to lock <0x0000000780991488> (a java.lang.String)
        - locked <0x00000007809914c0> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at lock.HoldLock.run(DeadLockDemo.java:38)
        - waiting to lock <0x00000007809914c0> (a java.lang.String)
        - locked <0x0000000780991488> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

在这里插入图片描述

我们发现线程Thread-1在等待0x0000000780991488这个锁，而线程Thread-0是持有0x0000000780991488这个锁的，相反线程Thread-1持有0x00000007809914c0这个锁，而线程Thread-0是在等待0x00000007809914c0这个锁；从而造成死锁；

预防死锁的办法

破坏请求和保持条件：1.一次性的申请所有资源。之后不在申请资源，如果不满足资源条件则得不到资源分配。2.只获得初期资源运行，之后将运行完的资源释放，请求新的资源。

破坏不可抢占条件：当一个进程获得某种不可抢占资源，提出新的资源申请，若不能满足，则释放所有资源，以后需要，再次重新申请。

破坏循环等待条件：对资源进行排号，按照序号递增的顺序请求资源。若进程获得序号高的资源想要获取序号低的资源，就需要先释放序号高的资源。

一路

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Java之死锁定位分析

什么是死锁死锁是值两个或者两个进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力干涉那它们都将无法推进下去；如果资源充足，进程的资源请求都能得到满足，死锁出现的可能性就很低，否则将会因争夺有限的资源而陷入死锁；产生死锁的主要原因：系统资源不足；进程运行推进的顺序不合适；资源分配不当；形成死锁的四个必要条件：（1）互斥条件：一个资源每次只能被一个进程使用。（2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。（3）不剥夺条件:进程已获得的资源，在末使用完之
复制链接

扫一扫