Java线程死锁以及问题定位

最新推荐文章于 2024-04-08 22:47:07 发布

-清风明月-

最新推荐文章于 2024-04-08 22:47:07 发布

阅读量2.9k

点赞数

分类专栏： Java Java多线程并发编程文章标签： java

本文链接：https://blog.csdn.net/weixin_38296425/article/details/119516671

版权

Java 同时被 3 个专栏收录

12 篇文章 0 订阅

订阅专栏

Java多线程

5 篇文章 0 订阅

订阅专栏

并发编程

5 篇文章 0 订阅

订阅专栏

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够碍到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。

产生死锁主要原因:

系统资源不足
进程运行推进的顺序不合适
资源分配不当

发生死锁的四个条件：

互斥条件，线程使用的资源至少有一个不能共享的。
至少有一个线程必须持有一个资源且正在等待获取一个当前被别的线程持有的资源。
资源不能被抢占。
循环等待。

如何解决死锁问题

破坏发生死锁的四个条件其中之一即可。

实现死锁的代码案例：


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

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

    public void run(){
        synchronized (lockA){
            System.out.println(Thread.currentThread().getName()+" 持有"+lockA+" 想要获得 "+lockB);

            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            synchronized (lockB){
                System.out.println(Thread.currentThread().getName()+" 同时持有"+lockB+" 想要获得 "+lockA);
            }
        }
    }
}

测试类：

public class DeadLockDemo {
    public static void main(String[] args) {
        String lockA = "lockA";
        String lockB = "lockB";
        new Thread(new DeadLockData(lockB,lockA),"B").start();
        new Thread(new DeadLockData(lockA,lockB),"A").start();
    }
}

运行结果：

B 持有lockB 想要获得 lockA
A 持有lockA 想要获得 lockB

然后程序就就卡住了，不会输出同时持有的提示。

查看是否出现死锁，找到证据，使用两个工具：

jps
jps是jdk提供的一个查看当前java进程的小工具，可以看做是JavaVirtual Machine Process Status Tool的缩写。非常简单实用.
命令格式：jps [options ] [ hostid ]

[options]选项：
-q：仅输出VM标识符，不包括classname,jar name,arguments in main method
-m：输出main method的参数
-l：输出完全的包名，应用主类名，jar的完全路径名
-v：输出jvm参数
-V：输出通过flag文件传递到JVM中的参数(.hotspotrc文件或-XX:Flags=所指定的文件
-Joption：传递参数到vm,例如:-J-Xms512m
jstack
jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息

C:\gitcode\springboot\spring-boot>jps -l
1984 cn.qch.springbootlogback.base.blockqueue.DeadLockDemo
10548 org.jetbrains.jps.cmdline.Launcher
1940 org.jetbrains.kotlin.daemon.KotlinCompileDaemon
2904
12156 sun.tools.jps.Jps

C:\gitcode\springboot\spring-boot>

根据jsp -l的执行结果，找到程序包的路径，上图的位置：
1984 cn.huanzi.qch.springbootlogback.base.blockqueue.DeadLockDemo
其中1984是进程ID
然后使用jstack查看这个进程的堆栈信息：

C:\gitcode\springboot\spring-boot>jstack 1984
2021-08-08 16:49:18
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):

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

"A" #12 prio=5 os_prio=0 tid=0x000000001b970800 nid=0x29b0 waiting for monitor entry [0x000000001c49f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aab8> (a java.lang.String)
        - locked <0x0000000780f6aa80> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

"B" #11 prio=5 os_prio=0 tid=0x000000001b958800 nid=0x3120 waiting for monitor entry [0x000000001c2fe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aa80> (a java.lang.String)
        - locked <0x0000000780f6aab8> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

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

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001abbd800 nid=0x1768 runnable [0x000000001b31e000]
   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 <0x0000000781024378> (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 <0x0000000781024378> (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=0x000000001a93c000 nid=0x2044 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001968d000 nid=0x2b94 in Object.wait() [0x000000001a91e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000780d08ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000780d08ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

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

"VM Thread" os_prio=2 tid=0x000000001963e800 nid=0x26e0 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000001f70000 nid=0x3084 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000001f72000 nid=0x2708 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000001f73800 nid=0x1500 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000001f75000 nid=0x2e70 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001acdc800 nid=0x2d04 waiting on condition

JNI global references: 33


Found one Java-level deadlock:
=============================
"A":
  waiting to lock monitor 0x000000001964a328 (object 0x0000000780f6aab8, a java.lang.String),
  which is held by "B"
"B":
  waiting to lock monitor 0x000000001964c9a8 (object 0x0000000780f6aa80, a java.lang.String),
  which is held by "A"

Java stack information for the threads listed above:
===================================================
"A":
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aab8> (a java.lang.String)
        - locked <0x0000000780f6aa80> (a java.lang.String)

C:\gitcode\springboot\spring-boot>jstack 1984
2021-08-08 16:59:27
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):

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

"A" #12 prio=5 os_prio=0 tid=0x000000001b970800 nid=0x29b0 waiting for monitor entry [0x000000001c49f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aab8> (a java.lang.String)
        - locked <0x0000000780f6aa80> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

"B" #11 prio=5 os_prio=0 tid=0x000000001b958800 nid=0x3120 waiting for monitor entry [0x000000001c2fe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aa80> (a java.lang.String)
        - locked <0x0000000780f6aab8> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

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

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001abbd800 nid=0x1768 runnable [0x000000001b31e000]
   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 <0x0000000781024378> (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 <0x0000000781024378> (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=0x000000001a93c000 nid=0x2044 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001968d000 nid=0x2b94 in Object.wait() [0x000000001a91e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000780d08ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000780d08ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

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

"VM Thread" os_prio=2 tid=0x000000001963e800 nid=0x26e0 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000001f70000 nid=0x3084 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000001f72000 nid=0x2708 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000001f73800 nid=0x1500 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000001f75000 nid=0x2e70 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001acdc800 nid=0x2d04 waiting on condition

JNI global references: 33


Found one Java-level deadlock:
=============================
"A":
  waiting to lock monitor 0x000000001964a328 (object 0x0000000780f6aab8, a java.lang.String),
  which is held by "B"
"B":
  waiting to lock monitor 0x000000001964c9a8 (object 0x0000000780f6aa80, a java.lang.String),
  which is held by "A"

Java stack information for the threads listed above:
===================================================
"A":
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aab8> (a java.lang.String)
        - locked <0x0000000780f6aa80> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)
"B":
        at cn. qch.springbootlogback.base.blockqueue.DeadLockData.run(DeadLockDemo.java:26)
        - waiting to lock <0x0000000780f6aa80> (a java.lang.String)
        - locked <0x0000000780f6aab8> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.


C:\gitcode\springboot\spring-boot>

其实只要看最后的提示：Found 1 deadlock就会明白发生了死锁。
然后向上找到：Java stack information for the threads listed above:
可以看到
"A": waiting to lock <0x0000000780f6aab8> locked <0x0000000780f6aa80>
说明是A锁住了0x0000000780f6aa80 等待0x0000000780f6aab8
"B":waiting to lock <0x0000000780f6aa80> locked <0x0000000780f6aab8>
说明是B锁住了0x0000000780f6aab8 等待0x0000000780f6aa80

恰好符合线程死锁的条件，只要打破死锁的任何一个条件即可解决问题。

-清风明月-

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Java线程死锁以及问题定位

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够碍到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。产生死锁主要原因:系统资源不足进程运行推进的顺序不合适资源分配不当发生死锁的四个条件：互斥条件，线程使用的资源至少有一个不能共享的。至少有一个线程必须持有一个资源且正在等待获取一个当前被别的线程持有的资源。资源不能被抢占。循环等待。如何解决死锁问.
复制链接

扫一扫