1 字節(jié)碼層實(shí)現(xiàn)

javap 生成的字節(jié)碼中包含如下指令：

• monitorenter
• monitorexit

synchronized基此實(shí)現(xiàn)了簡單直接的鎖的獲取和釋放。

當(dāng)JVM的解釋器執(zhí)行monitorenter時(shí)會(huì)進(jìn)入到
InterpreterRuntime.cpp的

1.1 InterpreterRuntime::monitorenter

1.1.1 函數(shù)參數(shù) JavaThread *thread

封裝 Java線程 幀狀態(tài)的與機(jī)器/操作系統(tǒng)相關(guān)的部分的對(duì)象，這里傳參代表程序中的當(dāng)前線程BasicObjectLock *elem

BasicLock 類型的 _lock 對(duì)象主要用來保存 _obj 對(duì)象的對(duì)象頭數(shù)據(jù)：

1.1.2 函數(shù)體

UseBiasedLocking 標(biāo)識(shí)JVM是否開啟偏向鎖功能

• 如果開啟則執(zhí)行fast_enter邏輯
• 否則執(zhí)行slow_enter

 2 偏向鎖

 2.1 偏向鎖的意義

無多線程競爭時(shí)，盡量減少不必要的輕量級(jí)鎖執(zhí)行路徑。

輕量級(jí)鎖的獲取及釋放依賴多次的CAS操作，而偏向鎖只依賴一次CAS置換ThreadID。

當(dāng)存在高度的鎖競爭和低數(shù)據(jù)競爭時(shí)，RTM 鎖最有用。
高鎖爭用情況下，鎖通常會(huì)膨脹，而偏向鎖不適于這種情況。
RTM 鎖代碼要求關(guān)閉偏向鎖。

注意：我們不能在 get_processor_features() 中關(guān)閉 UseBiasedLocking，因?yàn)樗?Thread::allocate() 使用，它在 VM_Version::initialize() 之前調(diào)用。

if (UseRTMLocking && UseBiasedLocking) {
  if (FLAG_IS_DEFAULT(UseBiasedLocking)) {
    FLAG_SET_DEFAULT(UseBiasedLocking, false);
  } else {
    warning("Biased locking is not supported with RTM locking; ignoring UseBiasedLocking flag." );
    UseBiasedLocking = false;
  }
}

一旦出現(xiàn)多個(gè)線程競爭時(shí)必須撤銷偏向鎖，所以：

撤銷偏向鎖消耗的性能必須 ＜ 之前節(jié)省下來的CAS原子操作的性能消耗

不然得不償失!

JDK 6中默認(rèn)開啟偏向鎖，可以通過-XX:-UseBiasedLocking禁用偏向鎖。

• 偏向鎖的入口位于synchronizer.cpp文件的ObjectSynchronizer::fast_enter函數(shù)
  

2.2 偏向鎖的獲取

由BiasedLocking::revoke_and_rebias方法實(shí)現(xiàn)

2.2.1 markOop mark = obj->mark()

獲取對(duì)象的markOop數(shù)據(jù)mark，即對(duì)象頭的Mark Word

2.2.2 判斷mark是否為可偏向狀態(tài)

•  mark的偏向鎖標(biāo)志位為 1 鎖標(biāo)志位為 01

2.2.3 判斷mark中JavaThread的狀態(tài)

如果為空，則進(jìn)入步驟（4）；如果指向當(dāng)前線程，則執(zhí)行同步代碼塊；如果指向其它線程，進(jìn)入步驟（5）；

2.2.4 通過CAS原子指令

設(shè)置mark中JavaThread為當(dāng)前線程ID，如果執(zhí)行CAS成功，則執(zhí)行同步代碼塊，否則進(jìn)入步驟（5）；

2.2.5 如果執(zhí)行CAS失敗

表示當(dāng)前存在多個(gè)線程競爭鎖，當(dāng)達(dá)到全局安全點(diǎn)（safepoint），獲得偏向鎖的線程被掛起，撤銷偏向鎖，并升級(jí)為輕量級(jí)，升級(jí)完成后被阻塞在安全點(diǎn)的線程繼續(xù)執(zhí)行同步代碼塊；

2.3 偏向鎖的撤銷

只有當(dāng)其它線程嘗試競爭偏向鎖時(shí)，持有偏向鎖的線程才會(huì)釋放鎖，偏向鎖的撤銷由BiasedLocking::revoke_at_safepoint方法實(shí)現(xiàn)：

1、偏向鎖的撤銷動(dòng)作必須等待全局安全點(diǎn)；
2、暫停擁有偏向鎖的線程，判斷鎖對(duì)象是否處于被鎖定狀態(tài)；
3、撤銷偏向鎖，恢復(fù)到無鎖（標(biāo)志位為 01）或輕量級(jí)鎖（標(biāo)志位為 00）的狀態(tài)；

偏向鎖在Java 1.6之后是默認(rèn)啟用的，但在應(yīng)用程序啟動(dòng)幾秒鐘之后才激活，可以使用
-XX:BiasedLockingStartupDelay=0
參數(shù)關(guān)閉延遲，如果確定應(yīng)用程序中所有鎖通常情況下處于競爭狀態(tài)，可以通過
XX:-UseBiasedLocking=false
參數(shù)關(guān)閉偏向鎖。

2.4 輕量級(jí)鎖

2.4.1 引入輕量級(jí)鎖的目的

在多線程交替執(zhí)行同步塊的情況下，盡量避免重量級(jí)鎖引起的性能消耗，但是如果多個(gè)線程在同一時(shí)刻進(jìn)入臨界區(qū)，會(huì)導(dǎo)致輕量級(jí)鎖膨脹升級(jí)重量級(jí)鎖，所以輕量級(jí)鎖的出現(xiàn)并非是要替代重量級(jí)鎖

2.4.2 輕量級(jí)鎖的獲取

當(dāng)關(guān)閉偏向鎖功能，或多個(gè)線程競爭偏向鎖導(dǎo)致偏向鎖升級(jí)為輕量級(jí)鎖，會(huì)嘗試獲取輕量級(jí)鎖，其入口位于ObjectSynchronizer::slow_enter

1、markOop mark = obj->mark()方法獲取對(duì)象的markOop數(shù)據(jù)mark；
2、mark->is_neutral()方法判斷mark是否為無鎖狀態(tài)：mark的偏向鎖標(biāo)志位為 0，鎖標(biāo)志位為 01；
3、如果mark處于無鎖狀態(tài)，則進(jìn)入步驟（4），否則執(zhí)行步驟（6）；
4、把mark保存到BasicLock對(duì)象的_displaced_header字段；
5、通過CAS嘗試將Mark Word更新為指向BasicLock對(duì)象的指針，如果更新成功，表示競爭到鎖，則執(zhí)行同步代碼，否則執(zhí)行步驟（6）；
6、如果當(dāng)前mark處于加鎖狀態(tài)，且mark中的ptr指針指向當(dāng)前線程的棧幀，則執(zhí)行同步代碼，否則說明有多個(gè)線程競爭輕量級(jí)鎖，輕量級(jí)鎖需要膨脹升級(jí)為重量級(jí)鎖；

假設(shè)線程A和B同時(shí)執(zhí)行到臨界區(qū)if (mark->is_neutral())：
1、線程AB都把Mark Word復(fù)制到各自的_displaced_header字段，該數(shù)據(jù)保存在線程的棧幀上，是線程私有的；
2、Atomic::cmpxchg_ptr原子操作保證只有一個(gè)線程可以把指向棧幀的指針復(fù)制到Mark Word，假設(shè)此時(shí)線程A執(zhí)行成功，并返回繼續(xù)執(zhí)行同步代碼塊；
3、線程B執(zhí)行失敗，退出臨界區(qū)，通過ObjectSynchronizer::inflate方法開始膨脹鎖；

輕量級(jí)鎖的釋放

輕量級(jí)鎖的釋放通過ObjectSynchronizer::fast_exit完成。

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

重量級(jí)鎖

重量級(jí)鎖通過對(duì)象內(nèi)部的監(jiān)視器（monitor）實(shí)現(xiàn)，其中monitor的本質(zhì)是依賴于底層操作系統(tǒng)的Mutex Lock實(shí)現(xiàn)，操作系統(tǒng)實(shí)現(xiàn)線程之間的切換需要從用戶態(tài)到內(nèi)核態(tài)的切換，切換成本非常高。

鎖膨脹過程

鎖的膨脹過程通過ObjectSynchronizer::inflate函數(shù)實(shí)現(xiàn)

膨脹過程的實(shí)現(xiàn)比較復(fù)雜，截圖中只是一小部分邏輯，完整的方法可以查看synchronized.cpp，大概實(shí)現(xiàn)過程如下：
1、整個(gè)膨脹過程在自旋下完成；
2、mark->has_monitor()方法判斷當(dāng)前是否為重量級(jí)鎖，即Mark Word的鎖標(biāo)識(shí)位為 10，如果當(dāng)前狀態(tài)為重量級(jí)鎖，執(zhí)行步驟（3），否則執(zhí)行步驟（4）；
3、mark->monitor()方法獲取指向ObjectMonitor的指針，并返回，說明膨脹過程已經(jīng)完成；
4、如果當(dāng)前鎖處于膨脹中，說明該鎖正在被其它線程執(zhí)行膨脹操作，則當(dāng)前線程就進(jìn)行自旋等待鎖膨脹完成，這里需要注意一點(diǎn)，雖然是自旋操作，但不會(huì)一直占用cpu資源，每隔一段時(shí)間會(huì)通過os::NakedYield方法放棄cpu資源，或通過park方法掛起；如果其他線程完成鎖的膨脹操作，則退出自旋并返回；
5、如果當(dāng)前是輕量級(jí)鎖狀態(tài)，即鎖標(biāo)識(shí)位為 00，膨脹過程如下：

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

monitor競爭

當(dāng)鎖膨脹完成并返回對(duì)應(yīng)的monitor時(shí)，并不表示該線程競爭到了鎖，真正的鎖競爭發(fā)生在ObjectMonitor::enter方法中。

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

monitor等待

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

1、當(dāng)前線程被封裝成ObjectWaiter對(duì)象node，狀態(tài)設(shè)置成ObjectWaiter::TS_CXQ；
2、在for循環(huán)中，通過CAS把node節(jié)點(diǎn)push到_cxq列表中，同一時(shí)刻可能有多個(gè)線程把自己的node節(jié)點(diǎn)push到_cxq列表中；
3、node節(jié)點(diǎn)push到_cxq列表之后，通過自旋嘗試獲取鎖，如果還是沒有獲取到鎖，則通過park將當(dāng)前線程掛起，等待被喚醒，實(shí)現(xiàn)如下：

4、當(dāng)該線程被喚醒時(shí)，會(huì)從掛起的點(diǎn)繼續(xù)執(zhí)行，通過ObjectMonitor::TryLock嘗試獲取鎖，TryLock方法實(shí)現(xiàn)如下：

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

monitor釋放

當(dāng)某個(gè)持有鎖的線程執(zhí)行完同步代碼塊時(shí)，會(huì)進(jìn)行鎖的釋放，給其它線程機(jī)會(huì)執(zhí)行同步代碼，在HotSpot中，通過退出monitor的方式實(shí)現(xiàn)鎖的釋放，并通知被阻塞的線程，具體實(shí)現(xiàn)位于ObjectMonitor::exit方法中。

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

void ObjectMonitor::ExitEpilog(Thread * Self, ObjectWaiter * Wakee) {
  assert(_owner == Self, "invariant");

  // Exit protocol:
  // 1. ST _succ = wakee
  // 2. membar #loadstore|#storestore;
  // 2. ST _owner = NULL
  // 3. unpark(wakee)

  _succ = Wakee->_thread;
  ParkEvent * Trigger = Wakee->_event;

  // Hygiene -- once we've set _owner = NULL we can't safely dereference Wakee again.
  // The thread associated with Wakee may have grabbed the lock and "Wakee" may be
  // out-of-scope (non-extant).
  Wakee  = NULL;

  // Drop the lock
  OrderAccess::release_store(&_owner, (void*)NULL);
  OrderAccess::fence();                               // ST _owner vs LD in unpark()

  DTRACE_MONITOR_PROBE(contended__exit, this, object(), Self);
  Trigger->unpark();

  // Maintain stats and report events to JVMTI
  OM_PERFDATA_OP(Parks, inc());
}

3、被喚醒的線程，繼續(xù)執(zhí)行monitor的競爭；

總結(jié)

到此這篇關(guān)于Java同步關(guān)鍵字synchronize底層實(shí)現(xiàn)原理解析的文章就介紹到這了,更多相關(guān)java synchronize底層實(shí)現(xiàn)原理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論