it网站建设,视觉设计网站推荐,七牛云免费服务器,asp网站开发程序员死锁是两个或者两个以上的线程在执行过程中#xff0c;因争夺资源而造成的一种互斥等待现象#xff0c;若没有外界干涉那么它们将无法推进下去。如果系统资源不足#xff0c;进程的资源请求都得到满足#xff0c;死锁出现的可能性就很低#xff0c;否则就会因为争夺有限的…死锁是两个或者两个以上的线程在执行过程中因争夺资源而造成的一种互斥等待现象若没有外界干涉那么它们将无法推进下去。如果系统资源不足进程的资源请求都得到满足死锁出现的可能性就很低否则就会因为争夺有限的资源而陷入死锁。 死锁案例 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 prio5 os_prio0 tid0x0000000002ff3800 nid0x50cc waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLEt2 #13 prio5 os_prio0 tid0x000000002980d800 nid0x4c94 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 prio5 os_prio0 tid0x000000002980b000 nid0x4a84 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 prio9 os_prio0 tid0x0000000027c77000 nid0x50a4 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLEC1 CompilerThread3 #10 daemon prio9 os_prio2 tid0x0000000027b8a800 nid0x1dc8 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLEC2 CompilerThread2 #9 daemon prio9 os_prio2 tid0x0000000027b84000 nid0x2d4 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLEC2 CompilerThread1 #8 daemon prio9 os_prio2 tid0x0000000027b81000 nid0xa8 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLEC2 CompilerThread0 #7 daemon prio9 os_prio2 tid0x0000000027b7e800 nid0x39d8 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLEMonitor Ctrl-Break #6 daemon prio5 os_prio0 tid0x0000000027b64000 nid0x48fc runnable [0x000000002905e000]java.lang.Thread.State: RUNNABLEat 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 prio5 os_prio2 tid0x0000000027a11800 nid0x5384 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLESignal Dispatcher #4 daemon prio9 os_prio2 tid0x00000000279be000 nid0x4fc8 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLEFinalizer #3 daemon prio8 os_prio1 tid0x00000000262d3800 nid0x1204 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 prio10 os_prio2 tid0x00000000262cc800 nid0x4de4 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_prio2 tid0x0000000027982800 nid0x5298 runnableGC task thread#0 (ParallelGC) os_prio0 tid0x0000000003009000 nid0x4cbc runnableGC task thread#1 (ParallelGC) os_prio0 tid0x000000000300a800 nid0x3a54 runnableGC task thread#2 (ParallelGC) os_prio0 tid0x000000000300c000 nid0x4098 runnableGC task thread#3 (ParallelGC) os_prio0 tid0x000000000300d800 nid0x2e78 runnableGC task thread#4 (ParallelGC) os_prio0 tid0x000000000300f800 nid0x3f98 runnableGC task thread#5 (ParallelGC) os_prio0 tid0x0000000003012000 nid0xd60 runnableGC task thread#6 (ParallelGC) os_prio0 tid0x0000000003015000 nid0x3414 runnableGC task thread#7 (ParallelGC) os_prio0 tid0x0000000003016000 nid0x2204 runnableGC task thread#8 (ParallelGC) os_prio0 tid0x0000000003017800 nid0x4fbc runnableGC task thread#9 (ParallelGC) os_prio0 tid0x0000000003018800 nid0x49e8 runnableVM Periodic Task Thread os_prio2 tid0x0000000027ced000 nid0x4f44 waiting on conditionJNI global references: 335Found 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 t2Java 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持有。
