當我們談論最新版本的Sun Hotspot Java虛擬機1.6時，當您嘗試從java.util.concurrent.locks.Lock實現獲取鎖或輸入同步塊時，JVM將執行以下三種鎖類型：

• 有偏見的 ：有時即使在并發系統中也沒有爭用，并且在這種情況下，JVM不應從OS借用互斥鎖來執行鎖定。 熱點可以使用其自己的內部數據結構進行操作，以更有效的方式模擬鎖定。 例如，如果代碼的同步部分沒有實時并發執行，則JVM使用CAS操作將所有者線程ID分配給Java代碼中用作互斥對象的對象，并在傳遞CAS時另外存儲重入計數。 它是有偏鎖 -JVM完成的“最輕”的鎖類型。 重入次數將由鎖所有者線程更新，就像沒有CAS的通常本地變量一樣。 如果CAS失敗，則意味著另一個線程已經獲得了該鎖，在這種情況下，JVM 停止了互斥鎖所有者線程， 將線程上下文刷新到主內存中并檢查重入計數。 如果為0，則JVM將鎖升級為瘦型，否則升級為胖型 （我認為主要目的是等待時間，如果鎖很薄，則應該很小）。 注意 Hotspot使用與用于緩存標識哈希碼相同的字段在互斥對象中存儲所有者線程ID。 因此，如果您一次在互斥體上檢索到身份哈希碼，則即使已被用作偏向鎖定，它也無法用于偏向鎖定。 有關偏向鎖的更多信息，請參見David Dice的博客 。
• 薄 ：這是一個簡單的自旋鎖。 當旋轉時間非常小時，它有助于節省線程上下文切換的時間。 當一個線程嘗試獲取占用的互斥鎖時，它旋轉了一段時間直到鎖將被釋放。 旋轉次數基于內部JVM分辨率，并且可能取決于不同的因素：JVM收集的有關您的應用程序的統計信息，使用的線程數，CPU等等。 JVM確定精簡鎖何時變得無效，并將其升級為胖鎖。
• fat ：JVM請求操作系統互斥并使用OS調度程序引擎進行線程駐留和喚醒時，“最強”的鎖定類型。 它比以前的類型昂貴得多，因為在這種情況下，每次線程獲取并釋放鎖時，JVM都應直接與OS進行交互。

參考： JVM如何處理 Slava技術博客上的 JCG合作伙伴提供的鎖 。

• Erlang與Java內存架構
• Java Fork / Join進行并行編程
• Java內存模型–快速概述和注意事項
• Java中可怕的雙重檢查鎖定成語
• Java最佳實踐–隊列之戰和鏈接的ConcurrentHashMap