【java中的 嵌套管程锁死】

原文链接    作者：Jakob Jenkov

译者：余绍亮    校对：丁一

嵌套管程锁死类似于死锁， 下面是一个嵌套管程锁死的场景 

1. 线程1获得A对象的锁。
   
2. 线程1获得对象B的锁（同时持有对象A的锁）。
   
3. 线程1决定等待另一个线程的信号再继续。
   
4. 线程1调用B.wait()，从而释放了B对象上的锁，但仍然持有对象A的锁。
   
5. 
   
6. 线程2需要同时持有对象A和对象B的锁，才能向线程1发信号。
   
7. 线程2无法获得对象A上的锁，因为对象A上的锁当前正被线程1持有。
   
8. 线程2一直被阻塞，等待线程1释放对象A上的锁。
   
9. 
   
10. 线程1一直阻塞，等待线程2的信号，因此，不会释放对象A上的锁，
    
11.         而线程2需要对象A上的锁才能给线程1发信号……

复制代码

你可以能会说，这是个空想的场景，好吧，让我们来看看下面这个比较挫的Lock实现：

1. //lock implementation with nested monitor lockout problem
   
2. public class Lock{
   
3.         protected MonitorObject monitorObject = new MonitorObject();
   
4.         protected boolean isLocked = false;
   
5. 
   
6.         public void lock() throws InterruptedException{
   
7.                 synchronized(this){
   
8.                         while(isLocked){
   
9.                                 synchronized(this.monitorObject){
   
10.                                         this.monitorObject.wait();
    
11.                                 }
    
12.                         }
    
13.                         isLocked = true;
    
14.                 }
    
15.         }
    
16. 
    
17.         public void unlock(){
    
18.                 synchronized(this){
    
19.                         this.isLocked = false;
    
20.                         synchronized(this.monitorObject){
    
21.                                 this.monitorObject.notify();
    
22.                         }
    
23.                 }
    
24.         }
    
25. }

复制代码

可以看到，lock()方法首先在”this”上同步，然后在monitorObject上同步。如果isLocked等于false，因为线程不会继续调用monitorObject.wait()，那么一切都没有问题 。但是如果isLocked等于true，调用lock()方法的线程会在monitorObject.wait()上阻塞。

这里的问题在于，调用monitorObject.wait()方法只释放了monitorObject上的管程对象，而与”this“关联的管程对象并没有释放。换句话说，这个刚被阻塞的线程仍然持有”this”上的锁。

（校对注：如果一个线程持有这种Lock的时候另一个线程执行了lock操作）当一个已经持有这种Lock的线程想调用unlock(),就会在unlock()方法进入synchronized(this)块时阻塞。这会一直阻塞到在lock()方法中等待的线程离开synchronized(this)块。但是，在unlock中isLocked变为false，monitorObject.notify()被执行之后，lock()中等待的线程才会离开synchronized(this)块。

简而言之，在lock方法中等待的线程需要其它线程成功调用unlock方法来退出lock方法，但是，在lock()方法离开外层同步块之前，没有线程能成功执行unlock()。

结果就是，任何调用lock方法或unlock方法的线程都会一直阻塞。这就是嵌套管程锁死。

一个更现实的例子

你可能会说，这么挫的实现方式我怎么可能会做呢？你或许不会在里层的管程对象上调用wait或notify方法，但完全有可能会在外层的this上调。
有很多类似上面例子的情况。例如，如果你准备实现一个公平锁。你可能希望每个线程在它们各自的QueueObject上调用wait()，这样就可以每次唤醒一个线程。

下面是一个比较挫的公平锁实现方式：

1. //Fair Lock implementation with nested monitor lockout problem
   
2. public class FairLock {
   
3.         private boolean isLocked = false;
   
4.         private Thread lockingThread = null;
   
5.         private List waitingThreads =
   
6.                 new ArrayList();
   
7. 
   
8.         public void lock() throws InterruptedException{
   
9.                 QueueObject queueObject = new QueueObject();
   
10. 
    
11.                 synchronized(this){
    
12.                         waitingThreads.add(queueObject);
    
13. 
    
14.                         while(isLocked ||
    
15.                                 waitingThreads.get(0) != queueObject){
    
16. 
    
17.                                 synchronized(queueObject){
    
18.                                         try{
    
19.                                                 queueObject.wait();
    
20.                                         }catch(InterruptedException e){
    
21.                                                 waitingThreads.remove(queueObject);
    
22.                                                 throw e;
    
23.                                         }
    
24.                                 }
    
25.                         }
    
26.                         waitingThreads.remove(queueObject);
    
27.                         isLocked = true;
    
28.                         lockingThread = Thread.currentThread();
    
29.                 }
    
30.         }
    
31. 
    
32.         public synchronized void unlock(){
    
33.                 if(this.lockingThread != Thread.currentThread()){
    
34.                         throw new IllegalMonitorStateException(
    
35.                                 "Calling thread has not locked this lock");
    
36.                 }
    
37.                 isLocked = false;
    
38.                 lockingThread = null;
    
39.                 if(waitingThreads.size() > 0){
    
40.                         QueueObject queueObject = waitingThread.get(0);
    
41.                         synchronized(queueObject){
    
42.                                 queueObject.notify();
    
43.                         }
    
44.                 }
    
45.         }
    
46. }

复制代码

1. public class QueueObject {}

复制代码

乍看之下，嗯，很好，但是请注意lock方法是怎么调用queueObject.wait()的，在方法内部有两个synchronized块，一个锁定this，一个嵌在上一个synchronized块内部，它锁定的是局部变量queueObject。
当一个线程调用queueObject.wait()方法的时候，它仅仅释放的是在queueObject对象实例的锁，并没有释放”this”上面的锁。

现在我们还有一个地方需要特别注意， unlock方法被声明成了synchronized，这就相当于一个synchronized（this）块。这就意味着，如果一个线程在lock()中等待，该线程将持有与this关联的管程对象。所有调用unlock()的线程将会一直保持阻塞，等待着前面那个已经获得this锁的线程释放this锁，但这永远也发生不了，因为只有某个线程成功地给lock()中等待的线程发送了信号，this上的锁才会释放，但只有执行unlock()方法才会发送这个信号。

因此，上面的公平锁的实现会导致嵌套管程锁死。

嵌套管程锁死 VS 死锁

嵌套管程锁死与死锁很像：都是线程最后被一直阻塞着互相等待。

但是两者又不完全相同。在死锁中我们已经对死锁有了个大概的解释，死锁通常是因为两个线程获取锁的顺序不一致造成的，线程1锁住A，等待获取B，线程2已经获取了B，再等待获取A。如死锁避免中所说的，死锁可以通过总是以相同的顺序获取锁来避免。
但是发生嵌套管程锁死时锁获取的顺序是一致的。线程1获得A和B，然后释放B，等待线程2的信号。线程2需要同时获得A和B，才能向线程1发送信号。所以，一个线程在等待唤醒，另一个线程在等待想要的锁被释放。

不同点归纳如下：

1. 死锁中，二个线程都在等待对方释放锁。
   
2. 
   
3. 嵌套管程锁死中，线程1持有锁A，同时等待从线程2发来的信号，线程2需要锁A来发信号给线程1。

复制代码