Java那些“锁”事 - 死锁及排查

大后生大大大

已于 2023-07-29 00:09:29 修改

阅读量1.2k

点赞数

分类专栏： Java并发编程文章标签：死锁

于 2023-07-29 00:04:56 首次发布

本文链接：https://blog.csdn.net/qq_27062249/article/details/131989477

版权

Java并发编程专栏收录该内容

15 篇文章 0 订阅

订阅专栏

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

死锁案例

 public static void main(String[] args) {

        final Object a = new Object();
        final Object b = new Object();

        new Thread(() -> {
            synchronized (a) {
                try {
                    System.out.println(Thread.currentThread().getName() + ",持有a锁希望获得b锁");
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (b) {
                    System.out.println(Thread.currentThread() + ",成功获得b锁");
                }
            }
        }, "t1").start();

        new Thread(() -> {
            synchronized (b) {
                try {
                     System.out.println(Thread.currentThread().getName() + ",持有b锁希望获得a锁");
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (a) {
                    System.out.println(Thread.currentThread() + ",成功获得a锁");
                }
            }
        }, "t2").start();
    }

打印结果：

t1,持有a锁希望获得b锁
t2,持有b锁希望获得a锁

可以看到案例中，t1持有a锁，希望获得b锁。而t2持有b锁，希望获得a锁。t1和t2就僵持在这里，程序得不到终止。

排除死锁

通过jdk自带的工具、命令我们可以查看当前进程，以及进程中是否存在死锁情况。

jps -l

通过jps -l 我们可以看到当前系统中正在运行的java进程：

$ jps -l
18064 com.tlh.comf._死锁及排查
3568
10644 org.jetbrains.jps.cmdline.Launcher
16676 sun.tools.jps.Jps
19544 org.jetbrains.idea.maven.server.RemoteMavenServer

我们看到我们的死锁案例的进程id为：18064

jstack #{进程id}

通过jstack #{进程id}，我们可以查看当前进程中线程的情况和否存在死锁。比如，我们的死锁案例进程id为：18064。我们通过jstack 18064查看到的信息：

$ jstack 18064
2023-07-28 23:57:25
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.91-b15 mixed mode):

"DestroyJavaVM" #14 prio=5 os_prio=0 tid=0x0000000002ff3800 nid=0x50cc waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"t2" #13 prio=5 os_prio=0 tid=0x000000002980d800 nid=0x4c94 waiting for monitor entry [0x000000002a05e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.tlh.comf._死锁及排查.lambda$main$1(_死锁及排查.java:42)
        - waiting to lock <0x00000007161d8520> (a java.lang.Object)
        - locked <0x00000007161d8530> (a java.lang.Object)
        at com.tlh.comf._死锁及排查$$Lambda$2/824909230.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

"t1" #12 prio=5 os_prio=0 tid=0x000000002980b000 nid=0x4a84 waiting for monitor entry [0x0000000029f5f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.tlh.comf._死???及排查.lambda$main$0(_死锁及排查.java:28)
        - waiting to lock <0x00000007161d8530> (a java.lang.Object)
        - locked <0x00000007161d8520> (a java.lang.Object)
        at com.tlh.comf._死锁及排查$$Lambda$1/1534030866.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

"Service Thread" #11 daemon prio=9 os_prio=0 tid=0x0000000027c77000 nid=0x50a4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #10 daemon prio=9 os_prio=2 tid=0x0000000027b8a800 nid=0x1dc8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x0000000027b64000 nid=0x48fc runnable [0x000000002905e000]
   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:170)
        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 <0x00000007162cf3f0> (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 <0x00000007162cf3f0> (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=0x0000000027a11800 nid=0x5384 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x00000000262d3800 nid=0x1204 in Object.wait() [0x0000000028cfe000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000716008ee0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000716008ee0> (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=0x00000000262cc800 nid=0x4de4 in Object.wait() [0x0000000028bff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000716006b50> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x0000000716006b50> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x0000000027982800 nid=0x5298 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000003009000 nid=0x4cbc runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000300a800 nid=0x3a54 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000300c000 nid=0x4098 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000300d800 nid=0x2e78 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000000000300f800 nid=0x3f98 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000003012000 nid=0xd60 runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000003015000 nid=0x3414 runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000003016000 nid=0x2204 runnable

"GC task thread#8 (ParallelGC)" os_prio=0 tid=0x0000000003017800 nid=0x4fbc runnable

"GC task thread#9 (ParallelGC)" os_prio=0 tid=0x0000000003018800 nid=0x49e8 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x0000000027ced000 nid=0x4f44 waiting on condition

JNI global references: 335


Found one Java-level deadlock:
=============================
"t2":
  waiting to lock monitor 0x00000000262d0678 (object 0x00000007161d8520, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x00000000262d2e58 (object 0x00000007161d8530, a java.lang.Object),
  which is held by "t2"

Java stack information for the threads listed above:
===================================================
"t2":
        at com.tlh.comf._死锁及排查.lambda$main$1(_死锁及排查.java:42)
        - waiting to lock <0x00000007161d8520> (a java.lang.Object)
        - locked <0x00000007161d8530> (a java.lang.Object)
        at com.tlh.comf._死锁及排查$$Lambda$2/824909230.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)
"t1":
        at com.tlh.comf._死锁及排查.lambda$main$0(_死锁及排查.java:28)
        - waiting to lock <0x00000007161d8530> (a java.lang.Object)
        - locked <0x00000007161d8520> (a java.lang.Object)
        at com.tlh.comf._死锁及排查$$Lambda$1/1534030866.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

打印的信息中，最上部分我们可以看到t1和t2的状态均为：BLOCKED（阻塞）状态。打印信息的最下部分，我们可以看到：Found one Java-level deadlock，提示信息说，t2在等待 lock monitor 0x00000000262d0678,但是被t1持有。t1在等待lock monitor 0x00000000262d2e58，但是被t2持有。

大后生大大大

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Java那些“锁”事 - 死锁及排查

死锁是两个或者两个以上的线程在执行过程中，因争夺资源而造成的一种互斥等待现象，若没有外界干涉那么它们将无法推进下去。如果系统资源不足，进程的资源请求都得到满足，死锁出现的可能性就很低，否则就会因为争夺有限的资源而陷入死锁。
复制链接

扫一扫

专栏目录