JVM源碼分析之synchronized實現

“365篇原創計划”第十二篇。

 

今天呢！燈塔君跟大家講：

 

JVM源碼分析之synchronized實現

 

 

java內部鎖synchronized的出現，為多線程的並發執行提供了一個穩定的環境，有效的防止多個線程同時執行同一個邏輯，其實這篇文章應該寫在 JVM源碼分析之Object.wait/notify實現機制之前，本文不會講如何使用synchronized，以HotSpot1.7的虛擬機為例，對synchronized的實現進行深入分析。

 

synchronized的HotSpot實現依賴於對象頭的Mark Word，關於Mark Word的描述可以參考這篇文章JVM源碼分析之Java對象頭實現

 

synchronized字節碼實現

通過javap命令生成的字節碼中包含 ** monitorenter ** 和 ** monitorexit **指令。

synchronized關鍵字基於上述兩個指令實現了鎖的獲取和釋放過程，解釋器執行monitorenter時會進入到 InterpreterRuntime.cpp的 InterpreterRuntime::monitorenter函數，具體實現如下：

1、JavaThread thread指向java中的當前線程；

2、BasicObjectLock類型的elem對象包含一個BasicLock類型_lock對象和一個指向Object對象的指針_obj;

class BasicObjectLock {  BasicLock _lock;   // object holds the lock;  oop  _obj;   }

3、BasicLock類型_lock對象主要用來保存_obj指向Object對象的對象頭數據；

class BasicLock {    volatile markOop _displaced_header;}

4、UseBiasedLocking標識虛擬機是否開啟偏向鎖功能，如果開啟則執行fast_enter邏輯，否則執行slow_enter；

 

偏向鎖

引入偏向鎖的目的：在沒有多線程競爭的情況下，盡量減少不必要的輕量級鎖執行路徑，輕量級鎖的獲取及釋放依賴多次CAS原子指令，而偏向鎖只依賴一次CAS原子指令置換ThreadID，不過一旦出現多個線程競爭時必須撤銷偏向鎖，所以撤銷偏向鎖消耗的性能必須小於之前節省下來的CAS原子操作的性能消耗，不然就得不償失了。JDK 1.6中默認開啟偏向鎖，可以通過-XX:-UseBiasedLocking來禁用偏向鎖。

在HotSpot中，偏向鎖的入口位於synchronizer.cpp文件的ObjectSynchronizer::fast_enter函數：

 

偏向鎖的獲取

偏向鎖的獲取由BiasedLocking::revoke_and_rebias方法實現，由於實現比較長，就不貼代碼了，實現邏輯如下：

• 通過markOop mark = obj->mark()獲取對象的markOop數據mark，即對象頭的Mark Word；

• 判斷mark是否為可偏向狀態，即mark的偏向鎖標志位為 1，鎖標志位為 01；

• 判斷mark中JavaThread的狀態：如果為空，則進入步驟（4）；如果指向當前線程，則執行同步代碼塊；如果指向其它線程，進入步驟（5）；

• 通過CAS原子指令設置mark中JavaThread為當前線程ID，如果執行CAS成功，則執行同步代碼塊，否則進入步驟（5）；

• 如果執行CAS失敗，表示當前存在多個線程競爭鎖，當達到全局安全點（safepoint），獲得偏向鎖的線程被掛起，撤銷偏向鎖，並升級為輕量級，升級完成后被阻塞在安全點的線程繼續執行同步代碼塊；

 

偏向鎖的撤銷

只有當其它線程嘗試競爭偏向鎖時，持有偏向鎖的線程才會釋放鎖，偏向鎖的撤銷由 BiasedLocking::revoke_at_safepoint方法實現：.

1. 偏向鎖的撤銷動作必須等待全局安全點；

2. 暫停擁有偏向鎖的線程，判斷鎖對象是否處於被鎖定狀態；
3. 撤銷偏向鎖，恢復到無鎖（標志位為 01）或輕量級鎖（標志位為 00）的狀態；

偏向鎖在Java 1.6之后是默認啟用的，但在應用程序啟動幾秒鍾之后才激活，可以使用 - XX:BiasedLockingStartupDelay=0參數關閉延遲，如果確定應用程序中所有鎖通常情況下處於競爭狀態，可以通過 XX:-UseBiasedLocking=false參數關閉偏向鎖。

 

輕量級鎖

引入輕量級鎖的目的：在多線程交替執行同步塊的情況下，盡量避免重量級鎖引起的性能消耗，但是如果多個線程在同一時刻進入臨界區，會導致輕量級鎖膨脹升級重量級鎖，所以輕量級鎖的出現並非是要替代重量級鎖。

 

輕量級鎖的獲取

當關閉偏向鎖功能，或多個線程競爭偏向鎖導致偏向鎖升級為輕量級鎖，會嘗試獲取輕量級鎖，其入口位於ObjectSynchronizer::slow_enter

• markOop mark = obj->mark()方法獲取對象的markOop數據mark；
• mark->is_neutral()方法判斷mark是否為無鎖狀態：mark的偏向鎖標志位為 0，鎖標志位為 01；
• 如果mark處於無鎖狀態，則進入步驟（4），否則執行步驟（6）；
• 把mark保存到BasicLock對象的_displaced_header字段；
• 通過CAS嘗試將Mark Word更新為指向BasicLock對象的指針，如果更新成功，表示競爭到鎖，則執行同步代碼，否則執行步驟（6）；

• 如果當前mark處於加鎖狀態，且mark中的ptr指針指向當前線程的棧幀，則執行同步代碼，否則說明有多個線程競爭輕量級鎖，輕量級鎖需要膨脹升級為重量級鎖；

假設線程A和B同時執行到臨界區if (mark->is_neutral())：

1、線程AB都把Mark Word復制到各自的_displaced_header字段，該數據保存在線程的棧幀上，是線程私有的；

2、 Atomic::cmpxchg_ptr原子操作保證只有一個線程可以把指向棧幀的指針復制到Mark Word，假設此時線程A執行成功，並返回繼續執行同步代碼塊；

3、線程B執行失敗，退出臨界區，通過 ObjectSynchronizer::inflate方法開始膨脹鎖；

 

輕量級鎖的釋放

輕量級鎖的釋放通過 ObjectSynchronizer::fast_exit完成。

1、確保處於偏向鎖狀態時不會執行這段邏輯；
2、取出在獲取輕量級鎖時保存在BasicLock對象的mark數據dhw；
3、通過CAS嘗試把dhw替換到當前的Mark Word，如果CAS成功，說明成功的釋放了鎖，否則執行步驟（4）；
4、如果CAS失敗，說明有其它線程在嘗試獲取該鎖，這時需要將該鎖升級為重量級鎖，並釋放；

 

重量級鎖

重量級鎖通過對象內部的監視器（monitor）實現，其中monitor的本質是依賴於底層操作系統的Mutex Lock實現，操作系統實現線程之間的切換需要從用戶態到內核態的切換，切換成本非常高。

 

鎖膨脹過程

鎖的膨脹過程通過 ObjectSynchronizer::inflate函數實現

膨脹過程的實現比較復雜，截圖中只是一小部分邏輯，完整的方法可以查看synchronized.cpp，大概實現過程如下：

• 整個膨脹過程在自旋下完成；
• mark->has_monitor()方法判斷當前是否為重量級鎖，即Mark Word的鎖標識位為 10，如果當前狀態為重量級鎖，執行步驟（3），否則執行步驟（4）；
• mark->monitor()方法獲取指向ObjectMonitor的指針，並返回，說明膨脹過程已經完成；
• 如果當前鎖處於膨脹中，說明該鎖正在被其它線程執行膨脹操作，則當前線程就進行自旋等待鎖膨脹完成，這里需要注意一點，雖然是自旋操作，但不會一直占用cpu資源，每隔一段時間會通過os::NakedYield方法放棄cpu資源，或通過park方法掛起；如果其他線程完成鎖的膨脹操作，則退出自旋並返回；
• 如果當前是輕量級鎖狀態，即鎖標識位為 00，膨脹過程如下：

   

1、通過omAlloc方法，獲取一個可用的ObjectMonitor monitor，並重置monitor數據；
2、通過CAS嘗試將Mark Word設置為markOopDesc:INFLATING，標識當前鎖正在膨脹中，如果CAS失敗，說明同一時刻其它線程已經將Mark Word設置為markOopDesc:INFLATING，當前線程進行自旋等待膨脹完成；
3、如果CAS成功，設置monitor的各個字段：_header、_owner和_object等，並返回；

 

monitor競爭

當鎖膨脹完成並返回對應的monitor時，並不表示該線程競爭到了鎖，真正的鎖競爭發生在 ObjectMonitor::enter方法中。

1、通過CAS嘗試把monitor的_owner字段設置為當前線程；
2、如果設置之前的_owner指向當前線程，說明當前線程再次進入monitor，即重入鎖，執行_recursions ++ ，記錄重入的次數；
3、如果之前的_owner指向的地址在當前線程中，這種描述有點拗口，換一種說法：之前_owner指向的BasicLock在當前線程棧上，說明當前線程是第一次進入該monitor，設置_recursions為1，_owner為當前線程，該線程成功獲得鎖並返回；
4、如果獲取鎖失敗，則等待鎖的釋放；

 

monitor等待

monitor競爭失敗的線程，通過自旋執行ObjectMonitor::EnterI方法等待鎖的釋放，EnterI方法的部分邏輯實現如下：

1、當前線程被封裝成ObjectWaiter對象node，狀態設置成ObjectWaiter::TS_CXQ；
2、在for循環中，通過CAS把node節點push到_cxq列表中，同一時刻可能有多個線程把自己的node節點push到_cxq列表中；
3、node節點push到_cxq列表之后，通過自旋嘗試獲取鎖，如果還是沒有獲取到鎖，則通過park將當前線程掛起，等待被喚醒，實現如下：

4、當該線程被喚醒時，會從掛起的點繼續執行，通過 ObjectMonitor::TryLock嘗試獲取鎖，TryLock方法實現如下：

 

其本質就是通過CAS設置monitor的_owner字段為當前線程，如果CAS成功，則表示該線程獲取了鎖，跳出自旋操作，執行同步代碼，否則繼續被掛起；

 

monitor釋放

當某個持有鎖的線程執行完同步代碼塊時，會進行鎖的釋放，給其它線程機會執行同步代碼，在HotSpot中，通過退出monitor的方式實現鎖的釋放，並通知被阻塞的線程，具體實現位於ObjectMonitor::exit方法中。

1、如果是重量級鎖的釋放，monitor中的_owner指向當前線程，即THREAD == _owner；
2、根據不同的策略（由QMode指定），從cxq或EntryList中獲取頭節點，通過 ObjectMonitor::ExitEpilog方法喚醒該節點封裝的線程，喚醒操作最終由unpark完成，實現如下：

3、被喚醒的線程，繼續執行monitor的競爭；

 

希望通過本文的分析可以讓大家對synchronized關鍵字有更加深刻的理解。