jvm鎖

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

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

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

相關文章 ：

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

翻譯自: https://www.javacodegeeks.com/2011/05/how-jvm-handle-locks.html

jvm鎖

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的jvm锁_JVM如何处理锁的全部內容，希望文章能夠幫你解決所遇到的問題。

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