什么是死锁
死锁是指多个进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去;如果资源充足,进程的资源请求都能得到满足,死锁出现的可能性就很低,否则将会因争夺有限的资源而陷入死锁;
产生死锁的主要原因:系统资源不足;进程运行推进的顺序不合适;资源分配不当;
形成死锁的四个必要条件:
(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.只获得初期资源运行,之后将运行完的资源释放,请求新的资源。
破坏不可抢占条件:当一个进程获得某种不可抢占资源,提出新的资源申请,若不能满足,则释放所有资源,以后需要,再次重新申请。
破坏循环等待条件:对资源进行排号,按照序号递增的顺序请求资源。若进程获得序号高的资源想要获取序号低的资源,就需要先释放序号高的资源。