問題描述

為什么take()方法在判斷隊列中元素個數(shù)是否為0的時候使用了while循環(huán)，而不是if；

我認為，如果notEmpty.await()方法既然蘇醒返回了 ，那么此線程肯定拿到了lock。

而蘇醒的原因也是因為put()方法放入了新的元素，而其他線程無法拿到鎖，自然無法取走元素，那么此時對于拿到鎖的線程來說count肯定不為0了，應該放心的執(zhí)行 dequeue()獲取元素就可以了。 不知道作者使用了while是何意呢？

問題解答

“notEmpty.await()方法既然蘇醒返回了 ，那么此線程肯定拿到了 lock” 這句話是正確的。

假設你寫的代碼是：

if (count == 0) notEmpty.await();

可以明確的一點就是我們需要保證在 return dequeue() 之前需要滿足的一個條件是 count != 0。我們假設 線程A 此時拿到了 lock，那么 線程A 的 notEmpty.await() 此時便會停止阻塞，準備向下執(zhí)行 return dequeue()。但是假設在競爭激烈的條件下，線程A 拿到 lock 之后，準備執(zhí)行下一條 JVM 指令的時候，線程B 此時搶占了 lock，然后繼續(xù)向下執(zhí)行 return dequeue()，剛好使得 count 變?yōu)榱?0；而此時因為寫的只是 if(count == 0)，那么線程 A 在拿到 lock 之后，還是會繼續(xù)向下執(zhí)行 return dequeue()，從而導致了錯誤。

關于為什么wait()、await() 這樣當條件不滿足時就阻塞的方法一定要在 while 循環(huán)中使用，可以參考《Effective Java》第二版第 69 條（244 頁）。

public ArrayBlockingQueue(int capacity, boolean fair) { if (capacity <= 0)throw new IllegalArgumentException(); this.items = new Object[capacity]; lock = new ReentrantLock(fair); notEmpty = lock.newCondition(); //notEmpty 就是這個鎖的條件 notFull = lock.newCondition();}

所以在你這段代碼里當前隊列為空時（count==0），調用了notEmpty.await()，這段代碼對鎖是有影響的，實際上底層上已經釋放了鎖，只是這個方法保證了被喚醒時一定又能夠拿回鎖（當有元素放入隊列會調用notEmpty.signal()進行喚醒），那為什么需要使用while呢？因為insert后lock.unlock，未必notEmpty.await()立即被喚醒，可能之前插入一個線程運行remove方法