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

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

死锁案例

 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 中可以使用以下方式来排查死锁: 1. 使用 jstack 工具 jstack 工具可以查看 Java 进程的线程状态和调用栈信息,通过分析线程状态和调用栈信息,可以发现是否存在死锁。 使用方式: ``` jstack <pid> ``` 其中,`<pid>` 是 Java 进程的进程号。 2. 使用 jconsole 工具 jconsole 工具可以查看 Java 进程的线程、内存、CPU 等信息,通过分析线程信息,可以发现是否存在死锁。 使用方式: 1. 启动 Java 进程时添加参数: ``` -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false ``` 其中,`<port>` 是 jconsole 连接 Java 进程的端口号。 2. 启动 jconsole 工具,输入连接信息: ``` Remote Process:<hostname>:<port> ``` 其中,`<hostname>` 是 Java 进程所在主机的 IP 地址或者域名,`<port>` 是 Java 进程的端口号。 3. 在 jconsole 工具中选择“线程”选项卡,查看线程状态和调用栈信息,分析是否存在死锁。 3. 使用 VisualVM 工具 VisualVM 工具是一款免费的 Java 监控和分析工具,可以查看 Java 进程的线程、内存、CPU 等信息,通过分析线程信息,可以发现是否存在死锁。 使用方式: 1. 启动 Java 进程时添加参数: ``` -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false ``` 其中,`<port>` 是 VisualVM 连接 Java 进程的端口号。 2. 启动 VisualVM 工具,选择“远程”选项卡,输入连接信息: ``` <hostname>:<port> ``` 其中,`<hostname>` 是 Java 进程所在主机的 IP 地址或者域名,`<port>` 是 Java 进程的端口号。 3. 在 VisualVM 工具中选择“线程”选项卡,查看线程状态和调用栈信息,分析是否存在死锁

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值