未能獲取鎖的線程會發生什麼情況？

Question

未能獲取鎖定的線程（非自旋）會發生什麼情況？它進入BLOCKED狀態。它是如何被再次執行的？

Lock lck = new ReentrantLock(); 
lck.lock() 
try 
{ 
} 
finally 
{ 
    lck.unlock(); 
} 

Answer 1

調度程序（或底層的Lock實現）負責讓它再次運行。如果鎖定操作被轉換爲一個互斥量調用一直進入內核，調度器將不會重新調度線程，直到互斥量變爲可用;那麼OS調度程序將重新喚醒該線程。閱讀關於Context Switch的維基百科頁面以及從那裏的鏈接可能會提供更多關於所涉及的詳細機制的信息。你也可以直接看ReentrantLock的代碼，儘管這最終會將你的問題歸結爲一些基元組合，包括AbstractedQueuedSynchronizer，各種原子操作，也許LockSupport.park()和unpark()。如果您特別關心內核級別的阻塞/上下文切換，或者特別是如何在內核上實現各種Java基元（例如，j.u.c.Lock或原始對象監視器），您可能會擴大您的問題或提出新問題。

實際上，由於這樣做代價高昂，因此可以通過JVM或鎖定實現來優化。例如，線程實際上可能旋轉了一下，看看鎖是否在實際阻塞之前被釋放。

請注意，即使底層OS線程未被阻止，特別是在下面的性能白皮書中描述的自適應旋轉情況下，Java線程也可能會報告狀態BLOCKED。

有一些很好的資源來了解Java中的併發控制。領導萬神殿的是Java Concurrency in Practice。在HotSpot 6.0 in the Java SE 6 Performance Whitepaper和一些related slides一些有趣的同步性能的討論。

Answer 2

持有鎖的線程解鎖鎖，然後（或「a」）阻塞的線程被喚醒。如果持有該鎖的線程從不釋放該鎖（可能是因爲它在另一個資源上被阻塞），那麼就會發生死鎖。非旋轉鎖通常使用wait（）/ notify（）原語或類似的東西，以便當鎖再次可用時通知線程。

Answer 3

鎖定採集從未失敗。認爲它有尚未成功。

當然，也有某些情況下，它會永遠成功，但有其中線程通知的失敗和hellip的無過渡事件;它只是在等待。