Java--死锁以及死锁的排查

最近遇到了死锁的问题,所以这里分析并总结下死锁,给出一套排查解决方案。

死锁示例一

清单一

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");
        }
      }
    }
  }
}

清单一代码有点长,但是逻辑很简单,有两个临界区变量lockAlockB,线程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

jstackjcmd是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-1Thread-0锁的互斥导致的死锁。

有时候文件分析不是很容易看,此时可以借助一些工具来分析,比如http://gceasy.io/,其分析整理后使得结果更加容易看到。

资源死锁排查

由于资源没释放的死锁使用jstack等手段难以排查,这种棘手的问题一般要多次dump线程快照,参考kabutz/DeadlockLabJavaOne2012给出的经验主要有以下两种方式排查: 能够控制资源死锁的情况:

  1. 在死锁前dump出线程快照
  2. 在死锁后再次dump出线程快照
  3. 两者比较

已经死锁

  1. 每隔一段时间dump出线程快照
  2. 对比找到不会改变的那些线程再排查问题

应用自行检查

在Java中提供了ThreadMXBean类可以帮助开发者查找死锁,该查找效果与jstack一致,对于资源释放不当死锁是无法排查的。 使用方法如清单4所示,要注意的是死锁的排查不是一个很高效的流程,要注意对应用性能的影响。 清单四

ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
long[] threadsIds = threadMXBean.findDeadlockedThreads();

参考

http://ifeve.com/deadlock/ https://github.com/kabutz/DeadlockLabJavaOne2012

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏蓝天

从程序员角度看ELF

原文:http://xcd.blog.techweb.com.cn/archives/222.html

1044
来自专栏从零开始学自动化测试

python测试开发django-3.url配置

我们在浏览器访问一个网页是通过url地址去访问的,django管理url配置是在urls.py文件。当一个页面数据很多时候,通过会有翻页的情况,那么页数是不固定...

1203
来自专栏JavaQ

深入理解Spring系列之十二:@Transactional是如何工作的

结合Spring框架,在进行数据库操作的时候,经常使用@Transactional注解,工作经历中看到很多人使用方式都是错误的,没有深入理解过其原理,这是很危险...

3447
来自专栏Android 研究

Retrofit解析2之使用简介

前面介绍完RESTful之后,我们先来初步认识下Retrofit的使用"姿势"。本文的主要内容如下:

7993
来自专栏Java开发者杂谈

线程间通信

  如果一个多线程程序中每个线程处理的资源没有交集,没有依赖关系那么这是一个完美的处理状态。你不用去考虑临界区域(critical section),不用担心存...

3839
来自专栏蓝天

C/C++常见gcc编译链接错误解决方法

用“-Wl,-Bstatic”指定链接静态库,使用“-Wl,-Bdynamic”指定链接共享库,使用示例: -Wl,-Bstatic -lmysq...

3393
来自专栏美团技术团队

Node.js Stream - 实战篇

背景 前面两篇(基础篇和进阶篇)主要介绍流的基本用法和原理,本篇从应用的角度,介绍如何使用管道进行程序设计,主要内容包括: 管道的概念 Browserify的...

3835
来自专栏无题

《深入理解JVM》阅读笔记以及问题整理

对阅读周志明先生的《深入理解JVM》产生的疑问与感悟以及要点进行总结。 想这种技术书应该反复读,最近又阅览了一次,才对GC部分有了一个大概的框架,可是细节部分依...

3526
来自专栏Java编程技术

高并发编程必备基础(上)

借用Java并发编程实践中的话"编写正确的程序并不容易,而编写正常的并发程序就更难了",相比于顺序执行的情况,多线程的线程安全问题是微妙而且出乎意料的,因为在没...

1052
来自专栏安恒信息

s2-029 Apache Struts2 标签远程代码执行分析

>>>> 标签介绍 Struts2标签库提供了主题、模板支持,极大地简化了视图页面的编写,而且,struts2的主题、模板都提供了很好的扩展性。实现了更好的代码...

2766

扫码关注云+社区

领取腾讯云代金券