- 嵌套管程死鎖是如何發(fā)生的
- 具體的嵌套管程死鎖的例子
- 嵌套管程死鎖 vs 死鎖
嵌套管程鎖死類似于死鎖森枪， 下面是一個嵌套管程鎖死的場景：
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對象的鎖牺六。
線程1獲得對象B的鎖（同時持有對象A的鎖）。
線程1決定等待另一個線程的信號再繼續(xù)褒傅。
線程1調(diào)用B.wait()缎岗，從而釋放了B對象上的鎖遏佣，但仍然持有對象A的鎖。
線程2需要同時持有對象A和對象B的鎖讯壶，才能向線程1發(fā)信號料仗。
線程2無法獲得對象A上的鎖，因為對象A上的鎖當(dāng)前正被線程1持有伏蚊。
線程2一直被阻塞立轧，等待線程1釋放對象A上的鎖。
線程1一直阻塞，等待線程2的信號氛改，因此帐萎，不會釋放對象A上的鎖，
而線程2需要對象A上的鎖才能給線程1發(fā)信號……
我們看下面這個實際的例子：
//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葛躏，因為線程不會繼續(xù)調(diào)用monitorObject.wait()澈段，那么一切都沒有問題 。但是如果isLocked等于true舰攒，調(diào)用lock()方法的線程會在monitorObject.wait()上阻塞败富。
這里的問題在于，調(diào)用monitorObject.wait()方法只釋放了monitorObject上的管程對象芒率，而與”this“關(guān)聯(lián)的管程對象并沒有釋放囤耳。換句話說，這個剛被阻塞的線程仍然持有”this”上的鎖偶芍。
（校對注：如果一個線程持有這種Lock的時候另一個線程執(zhí)行了lock操作）當(dāng)一個已經(jīng)持有這種Lock的線程想調(diào)用unlock(),就會在unlock()方法進入synchronized(this)塊時阻塞充择。這會一直阻塞到在lock()方法中等待的線程離開synchronized(this)塊。但是匪蟀，在unlock中isLocked變?yōu)閒alse椎麦，monitorObject.notify()被執(zhí)行之后，lock()中等待的線程才會離開synchronized(this)塊材彪。
簡而言之观挎，在lock方法中等待的線程需要其它線程成功調(diào)用unlock方法來退出lock方法，但是段化，在lock()方法離開外層同步塊之前嘁捷，沒有線程能成功執(zhí)行unlock()。
結(jié)果就是显熏，任何調(diào)用lock方法或unlock方法的線程都會一直阻塞雄嚣。這就是嵌套管程鎖死。
具體的嵌套管程死鎖的例子
例如喘蟆，如果你準(zhǔn)備實現(xiàn)一個公平鎖缓升。你可能希望每個線程在它們各自的QueueObject上調(diào)用wait()，這樣就可以每次喚醒一個線程蕴轨。
//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();
}
}
}
}
乍看之下港谊，嗯，很好橙弱，但是請注意lock方法是怎么調(diào)用queueObject.wait()的歧寺，在方法內(nèi)部有兩個synchronized塊燥狰，一個鎖定this，一個嵌在上一個synchronized塊內(nèi)部成福，它鎖定的是局部變量queueObject碾局。
當(dāng)一個線程調(diào)用queueObject.wait()方法的時候，它僅僅釋放的是在queueObject對象實例的鎖奴艾，并沒有釋放”this”上面的鎖净当。
現(xiàn)在我們還有一個地方需要特別注意， unlock方法被聲明成了synchronized蕴潦，這就相當(dāng)于一個synchronized（this）塊像啼。這就意味著，如果一個線程在lock()中等待潭苞，該線程將持有與this關(guān)聯(lián)的管程對象忽冻。所有調(diào)用unlock()的線程將會一直保持阻塞，等待著前面那個已經(jīng)獲得this鎖的線程釋放this鎖此疹，但這永遠也發(fā)生不了僧诚，因為只有某個線程成功地給lock()中等待的線程發(fā)送了信號，this上的鎖才會釋放蝗碎，但只有執(zhí)行unlock()方法才會發(fā)送這個信號湖笨。
因此，上面的公平鎖的實現(xiàn)會導(dǎo)致嵌套管程鎖死蹦骑。
Nested Monitor Lockout vs. Deadlock
嵌套管程鎖死與死鎖很像：都是線程最后被一直阻塞著互相等待慈省。
但是兩者又不完全相同。在死鎖中我們已經(jīng)對死鎖有了個大概的解釋眠菇，死鎖通常是因為兩個線程獲取鎖的順序不一致造成的边败，線程1鎖住A，等待獲取B捎废，線程2已經(jīng)獲取了B笑窜，再等待獲取A。如死鎖避免中所說的登疗，死鎖可以通過總是以相同的順序獲取鎖來避免排截。但是發(fā)生嵌套管程鎖死時鎖獲取的順序是一致的。線程1獲得A和B谜叹，然后釋放B匾寝，等待線程2的信號搬葬。線程2需要同時獲得A和B荷腊，才能向線程1發(fā)送信號。所以急凰，一個線程在等待喚醒女仰，另一個線程在等待想要的鎖被釋放猜年。
不同點歸納如下：
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.
死鎖中，二個線程都在等待對方釋放鎖疾忍。
嵌套管程鎖死中乔外，線程1持有鎖A，同時等待從線程2發(fā)來的信號一罩，線程2需要鎖A來發(fā)信號給線程1杨幼。
