Java 并發機制底層實作 —— volatile 原理、synchronize 鎖優化機制

本書部分摘自《Java 并發編程的藝術》

概述

相信大家都很熟悉如何使用 Java 撰寫處理并發的代碼，也知道 Java 代碼在編譯后變成 Class 位元組碼，位元組碼被類加載器加載到 JVM 里，JVM 執行位元組碼，最終需要轉化為匯編指令在 CPU 上執行，因此，Java 中所使用的并發機制其實是依賴于 JVM 的實作和 CPU 的指令，所以了解 Java 并發機制的底層實作原理也是很有必要的

volatile 的應用

volatile 在多處理器開發中保證了共享變數的可見性，可見性的意思是當一個執行緒修改一個共享變數時，另外一個執行緒能立即讀取到修改過后的值

1. volatile 的定義

Java 語言規范第三版對 volatile 的定義如下：Java 編程語言允許執行緒訪問共享變數，為了確保共享變數能被準確和一致地更新，執行緒應該確保通過排它鎖單獨獲得這個變數，排它鎖可以使用 synchronized 實作，但 Java 提供了 volatile，在某些情況下比鎖更加方便，如果一個欄位被宣告成 volatile，Java 執行緒記憶體模型將確保所有執行緒看到這個變數的值是一致的

2. volatile 的實作原理

在 Java 中我們可以直接使用 volatile 關鍵字，但它的底層是怎么實作的呢？被 volatile 變數修飾的共享變數進行寫操作的時候會多生成一行匯編代碼，這行代碼使用了 Lock 指令，Lock 指令在多核處理器下會引發兩件事情：

• 將當前處理器快取行的資料寫回到系統記憶體
• 這個寫回記憶體的操作會使在其他 CPU 里快取了該記憶體地址的資料無效

為了提高處理速度，處理器不直接和記憶體進行通信，而是先將系統記憶體的資料讀到內部快取后再進行操作，但操作完后不知道何時會寫到記憶體，如果對宣告了 volatile 的變數進行寫操作，JVM 就會向處理器發送一條 Lock 前綴的指令，將這個變數所在快取行的資料寫回到系統記憶體，但其他處理器的快取還是舊值，為了保證各個處理器的快取是一致的，每個處理器會通過嗅探在總線上傳播的資料來檢查自己快取的值是不是過期了，當處理器發現自己快取行對應的記憶體地址被修改，就會將當前處理器的快取行設定為無效狀態，當處理器對這個資料進行修改操作時，會重新從系統記憶體中把資料讀到處理器快取里

synchronized 的應用

在多執行緒并發編程中 synchronized 一直是元老級角色，很多人稱呼它為重量級鎖，不過，隨著 JavaSE 1.6 對 synchronized 進行了各種優化之后，有些情況下它就并不那么重了

Java 中的每一個物件都可以作為鎖，具體表現為以下三種形式：

• 對于普通同步方法，鎖是當前實體物件
• 對于靜態同步方法，鎖是當前類的 Class 物件
• 對于同步方法塊，鎖是 Synchronized 括號里配置的物件

1. synchronized 原理

JVM 基于進入和退出 Monitor 物件來實作方法同步和代碼塊同步，但兩者的實作細節不一樣，代碼塊同步是使用 monitorenter 和 monitorexit 指令實作，而方法同步是使用另外一種方式實作，細節在 JVM 規范里并沒有詳細說明，但方法的同步同樣可以使用這兩個指令來實作

monitorenter 指令是在編譯后插入到同步代碼塊的開始位置，而 monitorexit 是插入到方法結束處和例外處，JVM 要保證每個 monitorenter 必須有對應的 monitorexit 與之配對，任何物件都有一個 monitor 與之相關聯，當且一個 monitor 被持有后，它將處于鎖定狀態，執行緒執行到 monitorenter 指令時，將會嘗試獲取物件所對應的 monitor 的所有權，即嘗試獲得物件的鎖

2. 鎖的升級

JavaSE 1.6 為了減少獲得鎖和釋放鎖帶來的性能消耗，引入了偏向鎖和輕量級鎖，因此在 JavaSE 1.6 中，鎖一共有四種狀態，級別從低到高依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態和重量級鎖狀態，這幾個狀態會隨著競爭情況逐漸升級，鎖可以升級但不能降級，這是為了提高獲得鎖和釋放鎖的效率

3. 偏向鎖

研究發現，大多數情況下，鎖不僅不存在多執行緒競爭，而且總是由同一執行緒多次獲得，偏向鎖，顧名思義，它會偏向于第一個訪問鎖的執行緒，如果在運行程序中，只有一個執行緒訪問，不存在多執行緒爭用的情況，就會給執行緒加一個偏向鎖，執行緒不需要觸發同步就能獲得鎖，降低獲得鎖的代價

• 偏向鎖的獲取

  當一個執行緒訪問同步塊并獲取鎖時，會在物件頭和堆疊幀中的鎖記錄里存盤鎖偏向的執行緒 ID，以后該執行緒在進入和退出同步塊時不需要進行 CAS 操作來加鎖和解鎖，只需測驗一下物件頭的 Mark Word 是否存盤著指向當前執行緒的偏向鎖，如果測驗成功，表示執行緒已經獲得鎖，否則再測驗一下 Mark Work 中偏向鎖的標識是否設定成 1（表示當前是偏向鎖），如果沒有設定，使用 CAS 競爭鎖，否則嘗試使用 CAS 將物件頭的偏向鎖指向當前執行緒

• 偏向鎖的撤銷

  偏向鎖只有遇到其他執行緒嘗試競爭偏向鎖時，持有偏向鎖的執行緒才會釋放鎖，執行緒不會主動去釋放偏向鎖，偏向鎖的撤銷，需要等待全域安全點（在這個時間點上沒有位元組碼正在執行），它首先會暫停擁有偏向鎖的執行緒，判斷持有偏向鎖的執行緒是否活動，如果執行緒不處于活動狀態，則將物件頭設定成無鎖狀態；如果物件仍然活著，撤銷偏向鎖后恢復到未鎖定或輕量級鎖的狀態

• 關閉偏向鎖

  偏向鎖在 Java6 和 Java7 里是默認開啟的，但是它在應用程式啟動幾秒之后才激活，如有必要可以使用 JVM 引數來關閉延遲：-XX:BiasedLockingStartupDelay = 0，如果你確定應用程式里所有的鎖通常情況下處于競爭狀態，可以通過 JVM 引數來關閉偏向鎖：-XX:-UseBiasedLocking = false，那么程式默認會進入輕量級鎖狀態

下圖是偏向鎖的獲得和撤銷流程

4. 輕量級鎖

傳統的重量級鎖性能往往不如人意，因為 monitorenter 與 monitorexit 這兩個控制多執行緒同步的 bytecode 原語，是 JVM 依賴作業系統的互斥量來實作的，互斥是一種會導致執行緒掛起，并在較短的時間內又需要重新調度回原執行緒的，較為消耗資源的操作，為了優化性能，從 Java6 開始引入了輕量級鎖的概念，輕量級鎖本意是為了減少多執行緒進入互斥的幾率，并不是要替代互斥，它利用了 CPU 原語 Compare-And-Swap（CAS），嘗試在進入互斥前，進行補救

• 輕量級鎖加鎖

  執行緒在執行同步塊之前，JVM 先在當前執行緒的堆疊幀中創建用于存盤鎖記錄的空間，并將物件頭中的 Mark Word 復制到鎖記錄中，官方稱為 Displaced Mark Word

  然后執行緒嘗試使用 CAS 將物件頭中的 Mark Word 替換為指向鎖記錄的指標，如果成功，當前執行緒獲得鎖，否則表示其他執行緒競爭鎖，當前執行緒嘗試使用自旋來獲取鎖

• 輕量級鎖解鎖

  輕量級鎖解鎖時，執行緒會使用原子的 CAS 操作將 Dispatch Mark Word 替換回到物件頭，如果成功，表示沒有競爭發生；如果失敗，表示當前鎖存在競爭，鎖就會膨脹成重量級鎖

下圖是輕量級鎖及膨脹流程圖

因為自旋會消耗 CPU，為了避免無用的自旋，一旦鎖升級為重量級鎖，就不會再恢復到輕量級鎖狀態，當鎖處于這個狀態下，其他執行緒試圖獲取鎖時，都會被阻塞，當持有鎖的執行緒釋放鎖之后會喚醒這些執行緒，被喚醒的執行緒就會進行新一輪的奪鎖之爭

5. 鎖的優缺點對比

標籤：其他

上一篇：SpringBoot進階教程(七十)SkyWalking

下一篇：作用域、鏈接屬性和存盤型別