相信大家都对Java线程死锁的概念并不陌生。本质上就是有两个线程在互相等待。这通常都是flat锁(synchronized)或者 ReentrantLock的锁排列引起的问题。
Found one Java-level deadlock:
=============================
"pool-1-thread-2":
waiting to lock monitor 0x0237ada4 (object 0x272200e8, a java.lang.Object),
which is held by "pool-1-thread-1"
"pool-1-thread-1":
waiting to lock monitor 0x0237aa64 (object 0x272200f0, a java.lang.Object),
which is held by "pool-1-thread-2"
还好就是HotSpot JVM通常都能帮你检测到这样的问题,但也不一定。最近一个死锁问题影响到了生产环境上的Oracle Service Bus(OSB),让我们有必要重新认识下这个经典的问题了,我们得找出那些隐藏的死锁。本文将通过一个简单的Java程序和一组特殊的锁顺序来演示一个连最新的HotSpot 1.7 JVM也无法检测到的死锁的现场。本文末后有个小视频,它将告诉你如何使用这个小程序来重现这一场景。
犯罪现场
我喜欢将严重的Java并发问题比作犯罪现场,因为在这里你就像一个探长一样。你的生产环境的故障就像是一次犯罪纪录。而你工作就是:
- 收集证据,线索(thread dump,日志,业务影响,加载的配置等)
- 询问受害人以及领域专家(比如支持团队,发布团队,供应商,客户等)
调查的下一步就是分析收集来的信息,通过切实的证据,建立一个嫌疑人列表。最后你需要缩小范围,定位出头号嫌疑犯。很明显,法律上讲的“无罪推断”在这里并不适用,我们甚至还反其道而行之。没有足够的证据你就没法完成上述的目标。下面你会看到,虽然HotSpot JVM无法检测出死锁,但这并不说明我们就对此束手无策了。
嫌疑人
从故障诊断上下文能看出,应用或者中间件的这段代码的运行模式有问题,它就是嫌犯。
- 获取了flat锁后,紧接着又去获取ReentrantLock的写锁(执行路径1)
- 先获取了ReentrantLock的读锁,然后去获取flat锁(执行路径2)
- 两个线程并发的执行,却执行顺序恰恰相反
上述的死锁排列条件可以用下图来更清楚的说明:
现在我们通过一个Java程序来重现这个场景,然后看下JVM输出的thread dump。
示例程序
上述的死锁条件是从我们的Oracle OSB服务的出现的问题中发现的。然后我们通过一段Java程序重现了它。从这你可以下载到我们程序完整的代码。这个程序其实就是创建了两个工作线程。每个线程执行不同的执行路径,并通过相反的顺序来获取共享对象上的锁。我们也创建了一个死锁检测线程来监控和纪录日志。现在,看下这两条执行路径的Java程序吧。
package org.ph.javaee.training8;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* A simple thread task representation
* @author Pierre-Hugues Charbonneau
*
*/
public class Task {
// Object used for FLAT lock
private final Object sharedObject = new Object();
// ReentrantReadWriteLock used for WRITE & READ locks
private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
/**
* Execution pattern #1
*/
public void executeTask1() {
// 1. Attempt to acquire a ReentrantReadWriteLock READ lock
lock.readLock().lock();
// Wait 2 seconds to simulate some work...
try { Thread.sleep(2000);}catch (Throwable any) {}
try {
// 2. Attempt to acquire a Flat lock...
synchronized (sharedObject) {}
}
// Remove the READ lock
finally {
lock.readLock().unlock();
}
System.out.println("executeTask1() :: Work Done!");
}
/**
* Execution pattern #2
*/
public void executeTask2() {
// 1. Attempt to acquire a Flat lock
synchronized (sharedObject) {
// Wait 2 seconds to simulate some work...
try { Thread.sleep(2000);}catch (Throwable any) {}
// 2. Attempt to acquire a WRITE lock
lock.writeLock().lock();
try {
// Do nothing
}
// Remove the WRITE lock
finally {
lock.writeLock().unlock();
}
}
System.out.println("executeTask2() :: Work Done!");
}
public ReentrantReadWriteLock getReentrantReadWriteLock() {
return lock;
}
}
死锁条件被触发的时候,我们也通过JVisualVM生成了一份JVM的thread dump文件。
从上面的thread dump可以看到,JVM并没有检测出这个死锁条件(它并没有提示发现了Java程序的死锁),不过很明显,这两个线程就是处于死锁的状态。
根本原因:ReentrantLock读锁的行为
目前我们发现的最主要的原因就是使用了 ReentrantLock的读锁。读锁的设计中并没有关于持有锁的概念(译注:也就是,你不知道哪个线程持有读锁了)。那么由于没有记录表明某个线程持有读锁,HotSpot JVM的死锁检测程序也无从得知发生了死锁现象。JVM在死锁检测方面已经改进不少了,不过我们发现像这样的特殊的死锁现象它还是检测不了。如果我们把执行路径2中的读锁换成了写锁,JVM就能够发现产生死锁了,这是为什么呢?
Found one Java-level deadlock:
=============================
"pool-1-thread-2":
waiting for ownable synchronizer 0x272239c0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
which is held by "pool-1-thread-1"
"pool-1-thread-1":
waiting to lock monitor 0x025cad3c (object 0x272236d0, a java.lang.Object),
which is held by "pool-1-thread-2"
Java stack information for the threads listed above:
===================================================
"pool-1-thread-2":
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x272239c0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.
parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.
acquireQueued(AbstractQueuedSynchronizer.java:867)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.
acquire(AbstractQueuedSynchronizer.java:1197)
at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
at org.ph.javaee.training8.Task.executeTask2(Task.java:54)
- locked <0x272236d0> (a java.lang.Object)
at org.ph.javaee.training8.WorkerThread2.run(WorkerThread2.java:29)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
"pool-1-thread-1":
at org.ph.javaee.training8.Task.executeTask1(Task.java:31)
- waiting to lock <0x272236d0> (a java.lang.Object)
at org.ph.javaee.training8.WorkerThread1.run(WorkerThread1.java:29)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
这是因为JVM会像纪录flat锁那样把写锁记录下来。这说明了HotSpot JVM死锁检测器目前的设计是为了检测以下现象的:
- 对象监视器上flat锁产生的死锁。
- Locked ownable synchronizers中包含写锁造成的死锁。
在这个场景中,由于没有记录线程使用的读锁,因此检测不出死锁,这会让问题更得相当棘手。我建议你读下Doug Lea对这整个问题的评论,他早在2005年就提出了如果添加线程对读锁的跟踪可能会再来潜在的开销(译注:这或者就是为什么JVM到现在也没有对读锁进行跟踪的原因,Doug Lea的影响力可是非常大的)。 如果你使用了读锁并怀疑程序因此产生了死锁,我建议:
-
密切分析线程调用栈,你会发现有的线程可能获取了读锁,导致另的线程无法获取写锁。
- 如果你是代码的owner,通过 lock.getReadLockCount() 来记录下读锁的数量。
原创文章转载请注明出处:
http://it.deepinmind.com
英文原文链接
想及时了解博客更新,可以关注我的微博
/deepinmind]Java译站
分享到:
相关推荐
当对于数据库某个表的某一列做更新或删除等操作,执行完毕后该条语句不提 交,另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态, 此时的现象是这条语句一直在执行,但一直没有执行成功,也没有...
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而... 由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了一种特殊现象死锁。
经常有初学的开发人员,由于对事务机制不熟悉,导致后台死锁,这可能导致用户大面积瘫痪,为了让技术人员快速的找到问题所在的机器,本人最近开发了一个简单的数据死锁查询工具,在我的项目上能快速的查到研发人员...
放掉共享锁,而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁,于是出现了死锁。 这种死锁比较隐蔽,但其实在稍大点的项目中经常发生。 解决方法: 让用户A的事务(即先读后写类型的操作),在select 时就是...
把银行家算法算法应用到操纵系统中对对临界资源的访问产生的死锁进行避免。假设共有3类资源A B C和五个进程编号为0—4。初始资源和初始矩阵要由用户自行控制。对某个资源的某次申请资源动作进行判断看是否能够将资源...
资源预分配法是指进程在运行前一次性地向系统申请它所需要的全部资源,如果系统当前不能够满足进程的全部资源请求,则不分配资源, 此进程暂不投入运行,如果系统当前能够满足进程的全部资源请求, 则一次性地将所申请...
哲学家的生活就是思考和吃饭,即思考,饿了就餐,再思考,...3.3.3 为了避免死锁,把哲学家分为三种状态,思考,饥饿,进食,仅当一个哲学家左右两边的筷子都可用时,才允许他拿筷子,并且一次拿到两只筷子,否则不拿。
既然是秘籍,显然是写一些大家不常找到的,MSDN里遗漏提示大家注意的东西。 用过.net 2.0中,自带SerialPort的人,大多都遇到过。莫名其妙的执行Close的时候会死掉的问题。而Wince,mobile下,甚至Write,WriteLine的...
GO,顺序执行演示到最后发生死锁或全部解开;资,新建资源的图标,在对话框中输入资源名称和资源个数的并确定后,在窗口任意部分单击鼠标左键,该位置便出现资源的图标(绿色方块),资源数显示为里面的圆,蓝色圆...
搞多线程的经常会遇到死锁的问题,学习操作系统的时候会讲到死锁相关的东西,我们用Python直观的演示一下。 死锁的一个原因是互斥锁。假设银行系统中,用户a试图转账100块给用户b,与此同时用户b试图转账200块给用户...
死锁的解除: 当死锁检测程序检测到有死锁存在时,一般采用两种方式来解除死锁: 1.终止进程:终止一个或多个涉及死锁的进程的执行,收回它们所占的资源再分配 。 2.抢夺资源:从涉及死锁的一个或几个进程中抢夺...
由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这产生了一种特殊现象死锁。 2、数据库 数据库(Database)是按照数据结构来组织、...
用一个10K电阻并在LM7805的5V输出端到地。 2、单片机的复位端的电容不能太大。 使用PIC单片机去设计工控电路,最头痛的问题,就是 PIC 单片机在受干扰后经常硬件死锁,大部份人归咎于“CMOS的可控硅效应” 因而...
想要在开发阶段检测到死锁是非常困难的,而想要解除死锁往往需要重新启动程序。更糟的是,死锁通常发生在负载重的生产过程中,而想要在测试中发现它,十分不易。之所以这么说,是因为测试线程之间所有可能的交叉是不...
以前接触到的数据库死锁,都是批量更新时加锁顺序不一致而导致的死锁,但是上周却遇到了一个很难理解的死锁。借着这个机会又重新学习了一下mysql的死锁知识以及常见的死锁场景。在多方调研以及和同事们的讨论下...
如果我们的业务处在一个非常初级的阶段,并发程度比较低,那么我们可以几年都遇不到一次死锁问题的发生,反之,我们业务的并发程度非常高,那么时不时爆出的死锁问题肯定让我们非常挠头。不过在死锁问题发生时,很多...
•互斥条件:指进程对所分配到的资源进行排它性使用,即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源,则请求者只能等待,直至占有资源的进程用毕释放 •请求和保持条件:指进程已经保持至少...
最近有项目需求,需要保证多台机器不拿到相同的数据,后来发现Mysql查询语句使用select.. for update经常导致数据库死锁问题,下面小编给大家介绍mysql 数据库死锁过程分析(select for update),对mysql数据库死锁...
之前接触到的数据库死锁,都是批量更新时加锁顺序不一致而导致的死锁,但是上周却遇到了一个很难理解的死锁。借着这个机会又重新学习了一下mysql的死锁知识以及常见的死锁场景。在多方调研以及和同事们的讨论下终于...
操作系统,关于进程调度与死锁,好东西啊,快点来下载啊,晚了就找不到了