·嵌套管程死鎖是如何發(fā)生的
·具體的嵌套管程死鎖的例子
·嵌套管程死鎖 vs 死鎖

嵌套管程鎖死類似于死鎖， 下面是一個(gè)嵌套管程鎖死的場(chǎng)景：

Thread 1 synchronizes on A
Thread 1 synchronizes on B (while synchronized on A)
Thread 1 decides to wait for a signal from another thread before continuing
Thread 1 calls B.wait() thereby releasing the lock on B, but not A.

Thread 2 needs to lock both A and B (in that sequence)
    to send Thread 1 the signal.
Thread 2 cannot lock A, since Thread 1 still holds the lock on A.
Thread 2 remain blocked indefinately waiting for Thread1
    to release the lock on A

Thread 1 remain blocked indefinately waiting for the signal from
    Thread 2, thereby
    never releasing the lock on A, that must be released to make
    it possible for Thread 2 to send the signal to Thread 1, etc.

線程1獲得A對(duì)象的鎖。
線程1獲得對(duì)象B的鎖（同時(shí)持有對(duì)象A的鎖）。
線程1決定等待另一個(gè)線程的信號(hào)再繼續(xù)。
線程1調(diào)用B.wait()，從而釋放了B對(duì)象上的鎖，但仍然持有對(duì)象A的鎖。

線程2需要同時(shí)持有對(duì)象A和對(duì)象B的鎖，才能向線程1發(fā)信號(hào)。
線程2無(wú)法獲得對(duì)象A上的鎖，因?yàn)閷?duì)象A上的鎖當(dāng)前正被線程1持有。
線程2一直被阻塞，等待線程1釋放對(duì)象A上的鎖。

線程1一直阻塞，等待線程2的信號(hào)，因此，不會(huì)釋放對(duì)象A上的鎖，
而線程2需要對(duì)象A上的鎖才能給線程1發(fā)信號(hào)……

我們看下面這個(gè)實(shí)際的例子：

//lock implementation with nested monitor lockout problem
public class Lock{
 protected MonitorObject monitorObject = new MonitorObject();
 protected boolean isLocked = false;
 public void lock() throws InterruptedException{
  synchronized(this){
   while(isLocked){
    synchronized(this.monitorObject){
      this.monitorObject.wait();
    }
   }
   isLocked = true;
  }
 }
 public void unlock(){
  synchronized(this){
   this.isLocked = false;
   synchronized(this.monitorObject){
    this.monitorObject.notify();
   }
  }
 }
}

可以看到，lock()方法首先在”this”上同步，然后在monitorObject上同步。如果isLocked等于false，因?yàn)榫€程不會(huì)繼續(xù)調(diào)用monitorObject.wait()，那么一切都沒有問題 。但是如果isLocked等于true，調(diào)用lock()方法的線程會(huì)在monitorObject.wait()上阻塞。

這里的問題在于，調(diào)用monitorObject.wait()方法只釋放了monitorObject上的管程對(duì)象，而與”this“關(guān)聯(lián)的管程對(duì)象并沒有釋放。換句話說(shuō)，這個(gè)剛被阻塞的線程仍然持有”this”上的鎖。

（校對(duì)注：如果一個(gè)線程持有這種Lock的時(shí)候另一個(gè)線程執(zhí)行了lock操作）當(dāng)一個(gè)已經(jīng)持有這種Lock的線程想調(diào)用unlock(),就會(huì)在unlock()方法進(jìn)入synchronized(this)塊時(shí)阻塞。這會(huì)一直阻塞到在lock()方法中等待的線程離開synchronized(this)塊。但是，在unlock中isLocked變?yōu)閒alse，monitorObject.notify()被執(zhí)行之后，lock()中等待的線程才會(huì)離開synchronized(this)塊。

簡(jiǎn)而言之，在lock方法中等待的線程需要其它線程成功調(diào)用unlock方法來(lái)退出lock方法，但是，在lock()方法離開外層同步塊之前，沒有線程能成功執(zhí)行unlock()。

結(jié)果就是，任何調(diào)用lock方法或unlock方法的線程都會(huì)一直阻塞。這就是嵌套管程鎖死。

具體的嵌套管程死鎖的例子

例如，如果你準(zhǔn)備實(shí)現(xiàn)一個(gè)公平鎖。你可能希望每個(gè)線程在它們各自的QueueObject上調(diào)用wait()，這樣就可以每次喚醒一個(gè)線程。

//Fair Lock implementation with nested monitor lockout problem
public class FairLock {
 private boolean      isLocked    = false;
 private Thread      lockingThread = null;
 private List<QueueObject> waitingThreads =
      new ArrayList<QueueObject>();
 public void lock() throws InterruptedException{
  QueueObject queueObject = new QueueObject();
  synchronized(this){
   waitingThreads.add(queueObject);
   while(isLocked || waitingThreads.get(0) != queueObject){
    synchronized(queueObject){
     try{
      queueObject.wait();
     }catch(InterruptedException e){
      waitingThreads.remove(queueObject);
      throw e;
     }
    }
   }
   waitingThreads.remove(queueObject);
   isLocked = true;
   lockingThread = Thread.currentThread();
  }
 }
 public synchronized void unlock(){
  if(this.lockingThread != Thread.currentThread()){
   throw new IllegalMonitorStateException(
    "Calling thread has not locked this lock");
  }
  isLocked   = false;
  lockingThread = null;
  if(waitingThreads.size() > 0){
   QueueObject queueObject = waitingThread.get(0);
   synchronized(queueObject){
    queueObject.notify();
   }
  }
 }
}

乍看之下，嗯，很好，但是請(qǐng)注意lock方法是怎么調(diào)用queueObject.wait()的，在方法內(nèi)部有兩個(gè)synchronized塊，一個(gè)鎖定this，一個(gè)嵌在上一個(gè)synchronized塊內(nèi)部，它鎖定的是局部變量queueObject。

當(dāng)一個(gè)線程調(diào)用queueObject.wait()方法的時(shí)候，它僅僅釋放的是在queueObject對(duì)象實(shí)例的鎖，并沒有釋放”this”上面的鎖。
現(xiàn)在我們還有一個(gè)地方需要特別注意， unlock方法被聲明成了synchronized，這就相當(dāng)于一個(gè)synchronized（this）塊。這就意味著，如果一個(gè)線程在lock()中等待，該線程將持有與this關(guān)聯(lián)的管程對(duì)象。所有調(diào)用unlock()的線程將會(huì)一直保持阻塞，等待著前面那個(gè)已經(jīng)獲得this鎖的線程釋放this鎖，但這永遠(yuǎn)也發(fā)生不了，因?yàn)橹挥心硞€(gè)線程成功地給lock()中等待的線程發(fā)送了信號(hào)，this上的鎖才會(huì)釋放，但只有執(zhí)行unlock()方法才會(huì)發(fā)送這個(gè)信號(hào)。

因此，上面的公平鎖的實(shí)現(xiàn)會(huì)導(dǎo)致嵌套管程鎖死。

Nested Monitor Lockout vs. Deadlock

嵌套管程鎖死與死鎖很像：都是線程最后被一直阻塞著互相等待。

但是兩者又不完全相同。在死鎖中我們已經(jīng)對(duì)死鎖有了個(gè)大概的解釋，死鎖通常是因?yàn)閮蓚€(gè)線程獲取鎖的順序不一致造成的，線程1鎖住A，等待獲取B，線程2已經(jīng)獲取了B，再等待獲取A。如死鎖避免中所說(shuō)的，死鎖可以通過總是以相同的順序獲取鎖來(lái)避免。但是發(fā)生嵌套管程鎖死時(shí)鎖獲取的順序是一致的。線程1獲得A和B，然后釋放B，等待線程2的信號(hào)。線程2需要同時(shí)獲得A和B，才能向線程1發(fā)送信號(hào)。所以，一個(gè)線程在等待喚醒，另一個(gè)線程在等待想要的鎖被釋放。

不同點(diǎn)歸納如下：

In deadlock, two threads are waiting for each other to release locks.
In nested monitor lockout, Thread 1 is holding a lock A, and waits
for a signal from Thread 2. Thread 2 needs the lock A to send the
signal to Thread 1.

死鎖中，二個(gè)線程都在等待對(duì)方釋放鎖。

嵌套管程鎖死中，線程1持有鎖A，同時(shí)等待從線程2發(fā)來(lái)的信號(hào)，線程2需要鎖A來(lái)發(fā)信號(hào)給線程1。

總結(jié)

以上就是本文關(guān)于Java并發(fā)之嵌套管程鎖死詳解的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站：java并發(fā)編程之cas詳解、java實(shí)現(xiàn)遍歷樹形菜單兩種實(shí)現(xiàn)代碼分享等，有什么問題可以隨時(shí)留言，小編會(huì)及時(shí)回復(fù)大家的。感謝朋友們對(duì)本站的支持！