原文鏈接? ??作者：Jakob Jenkov

譯者：余紹亮 ? ?校對：丁一

嵌套管程鎖死類似于死鎖， 下面是一個嵌套管程鎖死的場景：

線程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實現：

01	//lock implementation with nested monitor lockout problem

02	public?class?Lock{

03	????protected?MonitorObject monitorObject =?new?MonitorObject();

04	????protected?boolean?isLocked =?false;

05

?

06	????public?void?lock()?throws?InterruptedException{

07	????????synchronized(this){

08	????????????while(isLocked){

09	????????????????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()，這樣就可以每次喚醒一個線程。

下面是一個比較挫的公平鎖實現方式：

01	//Fair Lock implementation with nested monitor lockout problem

02	public?class?FairLock {

03	????private?boolean?isLocked =?false;

04	????private?Thread lockingThread =?null;

05	????private?List waitingThreads =

06	????????new?ArrayList();

07

?

08	????public?void?lock()?throws?InterruptedException{

09	????????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()方法才會發送這個信號。

因此，上面的公平鎖的實現會導致嵌套管程鎖死。更好的公平鎖實現方式可以參考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。

原創文章，轉載請注明：?轉載自并發編程網 – ifeve.com本文鏈接地址:?嵌套管程鎖死

總結

以上是生活随笔為你收集整理的嵌套管程锁死的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。