Java之死锁定位分析

什么是死锁

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

形成死锁的四个必要条件： （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.只获得初期资源运行，之后将运行完的资源释放，请求新的资源。

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

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