最近遇到了死锁的问题，所以这里分析并总结下死锁，给出一套排查解决方案。
死锁示例一
清单一
public class SynchronizedDeadLock {
private static final Object lockA = new Object();
private static final Object lockB = new Object();
/**
* ThreadA先获取lockA,在获取lockB
*/
private static class ThreadA extends java.lang.Thread {
@Override
public void run() {
// 获取临界区A
synchronized (lockA) {
System.out.println("get lockA success");
// 模拟耗时操作
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 获取临界区B
synchronized (lockB) {
System.out.println("get lockB success");
}
}
}
}
/**
* ThreadB先获取lockB,在获取lockA
*/
private static class ThreadB extends java.lang.Thread {
@Override
public void run() {
// 获取临界区A
synchronized (lockB) {
System.out.println("get lockB success");
// 模拟耗时操作
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 获取临界区B
synchronized (lockA) {
System.out.println("get lockA success");
}
}
}
}
}
清单一代码有点长，但是逻辑很简单，有两个临界区变量lockA，lockB，线程A先获取到lockA在获取lockB，线程B则与之相反顺序获取锁，那么就可能会有以下情况：
线程A获取到lockA之后发现lockB已被线程B获取，那么此时线程A进入blocked状态。同理线程B获取lockA时发现其被线程A获取，那么线程B也进入blocked状态，那么这就是死锁。
可以总结下，这种类型的死锁源于锁的嵌套，由于线程与线程之间的互相看对方都是乱序执行，因此加锁的顺序和释放顺序都是难以保证的，锁的互相嵌套在多线程下是一个很危险的操作，因此需要额外注意。
可以总结下，这种类型的死锁源于锁的嵌套，由于线程与线程之间的互相看对方都是乱序执行，因此加锁的顺序和释放顺序都是难以保证的，锁的互相嵌套在多线程下是一个很危险的操作，因此需要额外注意。
死锁示例二
清单二
public class TreeNode {
TreeNode parent = null;
List children = new ArrayList();
public synchronized void addChild(TreeNode child){
if(!this.children.contains(child)) {
this.children.add(child);
child.setParentOnly(this);
}
}
public synchronized void addChildOnly(TreeNode child){
if(!this.children.contains(child)){
this.children.add(child);
}
}
public synchronized void setParent(TreeNode parent){
this.parent = parent;
parent.addChildOnly(this);
}
public synchronized void setParentOnly(TreeNode parent){
this.parent = parent;
}
}
清单2的代码来自并发编程网-死锁，下方代码可以理解为一个组合模式，那么在多线程的环境下如果线程1调用parent.addChild(child)方法的同时有另外一个线程2调用child.setParent(parent)方法，两个线程中的parent表示的是同一个对象，child亦然，此时就会发生死锁。下面的伪代码说明了这个过程：
Thread 1: parent.addChild(child); //locks parent
--> child.setParentOnly(parent);
Thread 2: child.setParent(parent); //locks child
--> parent.addChildOnly()
也可以总结下：这种类型的死锁本质原因也是锁的嵌套问题，child.setParent(parent)该方法执行首先需要获取到child这个对象锁，然后其内部调用parent的方法则需要获取parent的对象锁，那么就形成了锁嵌套，因此会出现死锁。
死锁示例三
清单三是一种开发人员经常犯的错误,一般都是由于某些中断操作没有释放掉锁，所以也叫（Resource deadlock）比如下方的当i==5直接抛出异常，导致锁没有释放，所以对于资源释放语句一定要卸载finally中。
public void hello(int i) {
LOCK.lock();
System.out.println(Thread.currentThread().getName() + "--hello:"+i);
// 异常抛出但是没有释放掉锁
if (i == 5) {
throw new IllegalArgumentException("抛出异常,模拟获取锁后不释放");
}
LOCK.unlock();
}
这种死锁最可怕的地方是难以排查，使用jstack时无法分析出这一类的死锁，你大概能得到的反馈可能线程仍然处于RUNNABLE，具体排查方法看下方的死锁排查。
死锁的排查
jstack or jcmd
jstack与jcmd是JDK自带的工具包，使用jstack -l pid或者jcmd pid Thread.print可以查看当前应用的进程信息，如果有死锁也会分析出来。比如清单一中的死锁会分析出以下结果：
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x00007fbea28989b8 (object 0x000000076ac710a0, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00007fbea480a158 (object 0x000000076ac710b0, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at cn.mrdear.custom.lock.SynchronizedDeadLock$ThreadB.run(SynchronizedDeadLock.java:72)
- waiting to lock <0x000000076ac710a0> (a java.lang.Object)
- locked <0x000000076ac710b0> (a java.lang.Object)
"Thread-0":
at cn.mrdear.custom.lock.SynchronizedDeadLock$ThreadA.run(SynchronizedDeadLock.java:48)
- waiting to lock <0x000000076ac710b0> (a java.lang.Object)
- locked <0x000000076ac710a0> (a java.lang.Object)
Found 1 deadlock.
在分析中明确指出发现了死锁，是由于Thread-1与Thread-0锁的互斥导致的死锁。
有时候文件分析不是很容易看，此时可以借助一些工具来分析，比如
http://gceasy.io/，其分析整理后使得结果更加容易看到。
资源死锁排查
由于资源没释放的死锁使用jstack等手段难以排查，这种棘手的问题一般要多次dump线程快照，参考kabutz/DeadlockLabJavaOne2012给出的经验主要有以下两种方式排查：
能够控制资源死锁的情况：
- 在死锁前dump出线程快照
- 在死锁后再次dump出线程快照
- 两者比较
已经死锁
- 每隔一段时间dump出线程快照
- 对比找到不会改变的那些线程再排查问题
应用自行检查
在Java中提供了ThreadMXBean类可以帮助开发者查找死锁，该查找效果与jstack一致，对于资源释放不当死锁是无法排查的。
使用方法如清单4所示，要注意的是死锁的排查不是一个很高效的流程，要注意对应用性能的影响。
清单四
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
long[] threadsIds = threadMXBean.findDeadlockedThreads();
参考
http://ifeve.com/deadlock/
https://github.com/kabutz/DeadlockLabJavaOne2012
- 版权声明: 感谢您的阅读，本文由屈定's Blog版权所有。如若转载，请注明出处。
- 文章标题: Java--死锁以及死锁的排查
- 文章链接: https://mrdear.cn/2018/06/16/java/Java_study--deadlock/
