Java併發系列-16、巢狀鎖死
巢狀管程鎖死類似於死鎖, 下面是一個巢狀管程鎖死的場景:
執行緒1獲得A物件的鎖。 執行緒1獲得物件B的鎖(同時持有物件A的鎖)。 執行緒1決定等待另一個執行緒的訊號再繼續。 執行緒1呼叫B.wait(),從而釋放了B物件上的鎖,但仍然持有物件A的鎖。 執行緒2需要同時持有物件A和物件B的鎖,才能向執行緒1發訊號。 執行緒2無法獲得物件A上的鎖,因為物件A上的鎖當前正被執行緒1持有。 執行緒2一直被阻塞,等待執行緒1釋放物件A上的鎖。 執行緒1一直阻塞,等待執行緒2的訊號,因此,不會釋放物件A上的鎖,而執行緒2需要物件A上的鎖才能給執行緒1發訊號……
你可以能會說,這是個空想的場景,好吧,讓我們來看看下面這個比較挫的Lock實現:
//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,因為執行緒不會繼續呼叫monitorObject.wait(),那麼一切都沒有問題 。但是如果isLocked等於true,呼叫lock()方法的執行緒會在monitorObject.wait()上阻塞。
這裡的問題在於,呼叫monitorObject.wait()方法只釋放了monitorObject上的管程物件,而與”this“關聯的管程物件並沒有釋放。換句話說,這個剛被阻塞的執行緒仍然持有”this”上的鎖。
(校對注:如果一個執行緒持有這種Lock的時候另一個執行緒執行了lock操作
簡而言之,在lock方法中等待的執行緒需要其它執行緒成功呼叫unlock方法來退出lock方法,但是,在lock()方法離開外層同步塊之前,沒有執行緒能成功執行unlock()。
結果就是,任何呼叫lock方法或unlock方法的執行緒都會一直阻塞。這就是巢狀管程鎖死。
一個更現實的例子
你可能會說,這麼挫的實現方式我怎麼可能會做呢?你或許不會在裡層的管程物件上呼叫wait或notify方法,但完全有可能會在外層的this上調。
有很多類似上面例子的情況。例如,如果你準備實現一個公平鎖。你可能希望每個執行緒在它們各自的QueueObject上呼叫wait(),這樣就可以每次喚醒一個執行緒。
下面是一個比較挫的公平鎖實現方式:
//Fair Lock implementation with nested monitor lockout problem
public class FairLock {
private boolean isLocked = false;
private Thread lockingThread = null;
private List waitingThreads =
new ArrayList();
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方法是怎麼呼叫queueObject.wait()的,在方法內部有兩個synchronized塊,一個鎖定this,一個嵌在上一個synchronized塊內部,它鎖定的是區域性變數queueObject。
當一個執行緒呼叫queueObject.wait()方法的時候,它僅僅釋放的是在queueObject物件例項的鎖,並沒有釋放”this”上面的鎖。
現在我們還有一個地方需要特別注意, unlock方法被宣告成了synchronized,這就相當於一個synchronized(this)塊。這就意味著,如果一個執行緒在lock()中等待,該執行緒將持有與this關聯的管程物件。所有呼叫unlock()的執行緒將會一直保持阻塞,等待著前面那個已經獲得this鎖的執行緒釋放this鎖,但這永遠也發生不了,因為只有某個執行緒成功地給lock()中等待的執行緒傳送了訊號,this上的鎖才會釋放,但只有執行unlock()方法才會傳送這個訊號。
因此,上面的公平鎖的實現會導致巢狀管程鎖死。更好的公平鎖實現方式可以參考Starvation and Fairness。
巢狀管程鎖死 VS 死鎖
巢狀管程鎖死與死鎖很像:都是執行緒最後被一直阻塞著互相等待。
但是兩者又不完全相同。在死鎖中我們已經對死鎖有了個大概的解釋,死鎖通常是因為兩個執行緒獲取鎖的順序不一致造成的,執行緒1鎖住A,等待獲取B,執行緒2已經獲取了B,再等待獲取A。如死鎖避免中所說的,死鎖可以通過總是以相同的順序獲取鎖來避免。
但是發生巢狀管程鎖死時鎖獲取的順序是一致的。執行緒1獲得A和B,然後釋放B,等待執行緒2的訊號。執行緒2需要同時獲得A和B,才能向執行緒1傳送訊號。所以,一個執行緒在等待喚醒,另一個執行緒在等待想要的鎖被釋放。
不同點歸納如下:
死鎖中,二個執行緒都在等待對方釋放鎖。 巢狀管程鎖死中,執行緒1持有鎖A,同時等待從執行緒2發來的訊號,執行緒2需要鎖A來發訊號給執行緒1。