Java同步關(guān)鍵字synchronize底層實(shí)現(xiàn)原理解析
javap 生成的字節(jié)碼中包含如下指令:
monitorenter monitorexitsynchronized基此實(shí)現(xiàn)了簡(jiǎn)單直接的鎖的獲取和釋放。
當(dāng)JVM的解釋器執(zhí)行monitorenter時(shí)會(huì)進(jìn)入到InterpreterRuntime.cpp的
1.1 InterpreterRuntime::monitorenter1.1.1 函數(shù)參數(shù) JavaThread *thread封裝 Java線程 幀狀態(tài)的與機(jī)器/操作系統(tǒng)相關(guān)的部分的對(duì)象,這里傳參代表程序中的當(dāng)前線程BasicObjectLock *elem
BasicLock 類(lèi)型的 _lock 對(duì)象主要用來(lái)保存 _obj 對(duì)象的對(duì)象頭數(shù)據(jù):
UseBiasedLocking 標(biāo)識(shí)JVM是否開(kāi)啟偏向鎖功能
如果開(kāi)啟則執(zhí)行fast_enter邏輯 否則執(zhí)行slow_enter 2 偏向鎖 2.1 偏向鎖的意義無(wú)多線程競(jìng)爭(zhēng)時(shí),盡量減少不必要的輕量級(jí)鎖執(zhí)行路徑。
輕量級(jí)鎖的獲取及釋放依賴多次的CAS操作,而偏向鎖只依賴一次CAS置換ThreadID。
當(dāng)存在高度的鎖競(jìng)爭(zhēng)和低數(shù)據(jù)競(jìng)爭(zhēng)時(shí),RTM 鎖最有用。高鎖爭(zhēng)用情況下,鎖通常會(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è)線程競(jìng)爭(zhēng)時(shí)必須撤銷(xiāo)偏向鎖,所以:
撤銷(xiāo)偏向鎖消耗的性能必須 < 之前節(jié)省下來(lái)的CAS原子操作的性能消耗
不然得不償失!
JDK 6中默認(rèn)開(kāi)啟偏向鎖,可以通過(guò)-XX:-UseBiasedLocking禁用偏向鎖。
偏向鎖的入口位于synchronizer.cpp文件的ObjectSynchronizer::fast_enter函數(shù)
由BiasedLocking::revoke_and_rebias方法實(shí)現(xiàn)
獲取對(duì)象的markOop數(shù)據(jù)mark,即對(duì)象頭的Mark Word
如果為空,則進(jìn)入步驟(4);如果指向當(dāng)前線程,則執(zhí)行同步代碼塊;如果指向其它線程,進(jìn)入步驟(5);
2.2.4 通過(guò)CAS原子指令設(shè)置mark中JavaThread為當(dāng)前線程ID,如果執(zhí)行CAS成功,則執(zhí)行同步代碼塊,否則進(jìn)入步驟(5);
2.2.5 如果執(zhí)行CAS失敗表示當(dāng)前存在多個(gè)線程競(jìng)爭(zhēng)鎖,當(dāng)達(dá)到全局安全點(diǎn)(safepoint),獲得偏向鎖的線程被掛起,撤銷(xiāo)偏向鎖,并升級(jí)為輕量級(jí),升級(jí)完成后被阻塞在安全點(diǎn)的線程繼續(xù)執(zhí)行同步代碼塊;
2.3 偏向鎖的撤銷(xiāo)只有當(dāng)其它線程嘗試競(jìng)爭(zhēng)偏向鎖時(shí),持有偏向鎖的線程才會(huì)釋放鎖,偏向鎖的撤銷(xiāo)由BiasedLocking::revoke_at_safepoint方法實(shí)現(xiàn):
1、偏向鎖的撤銷(xiāo)動(dòng)作必須等待全局安全點(diǎn);2、暫停擁有偏向鎖的線程,判斷鎖對(duì)象是否處于被鎖定狀態(tài);3、撤銷(xiāo)偏向鎖,恢復(fù)到無(wú)鎖(標(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)用程序中所有鎖通常情況下處于競(jìng)爭(zhēng)狀態(tài),可以通過(guò)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è)線程競(jìng)爭(zhēng)偏向鎖導(dǎo)致偏向鎖升級(jí)為輕量級(jí)鎖,會(huì)嘗試獲取輕量級(jí)鎖,其入口位于ObjectSynchronizer::slow_enter
1、markOop mark = obj->mark()方法獲取對(duì)象的markOop數(shù)據(jù)mark;2、mark->is_neutral()方法判斷mark是否為無(wú)鎖狀態(tài):mark的偏向鎖標(biāo)志位為 0,鎖標(biāo)志位為 01;3、如果mark處于無(wú)鎖狀態(tài),則進(jìn)入步驟(4),否則執(zhí)行步驟(6);4、把mark保存到BasicLock對(duì)象的_displaced_header字段;5、通過(guò)CAS嘗試將Mark Word更新為指向BasicLock對(duì)象的指針,如果更新成功,表示競(jìng)爭(zhēng)到鎖,則執(zhí)行同步代碼,否則執(zhí)行步驟(6);6、如果當(dāng)前mark處于加鎖狀態(tài),且mark中的ptr指針指向當(dāng)前線程的棧幀,則執(zhí)行同步代碼,否則說(shuō)明有多個(gè)線程競(jìng)爭(zhēng)輕量級(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ū),通過(guò)ObjectSynchronizer::inflate方法開(kāi)始膨脹鎖;
輕量級(jí)鎖的釋放
輕量級(jí)鎖的釋放通過(guò)ObjectSynchronizer::fast_exit完成。
1、確保處于偏向鎖狀態(tài)時(shí)不會(huì)執(zhí)行這段邏輯;2、取出在獲取輕量級(jí)鎖時(shí)保存在BasicLock對(duì)象的mark數(shù)據(jù)dhw;3、通過(guò)CAS嘗試把dhw替換到當(dāng)前的Mark Word,如果CAS成功,說(shuō)明成功的釋放了鎖,否則執(zhí)行步驟(4);4、如果CAS失敗,說(shuō)明有其它線程在嘗試獲取該鎖,這時(shí)需要將該鎖升級(jí)為重量級(jí)鎖,并釋放;
重量級(jí)鎖
重量級(jí)鎖通過(guò)對(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)的切換,切換成本非常高。
鎖膨脹過(guò)程
鎖的膨脹過(guò)程通過(guò)ObjectSynchronizer::inflate函數(shù)實(shí)現(xiàn)
膨脹過(guò)程的實(shí)現(xiàn)比較復(fù)雜,截圖中只是一小部分邏輯,完整的方法可以查看synchronized.cpp,大概實(shí)現(xiàn)過(guò)程如下:1、整個(gè)膨脹過(guò)程在自旋下完成;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的指針,并返回,說(shuō)明膨脹過(guò)程已經(jīng)完成;4、如果當(dāng)前鎖處于膨脹中,說(shuō)明該鎖正在被其它線程執(zhí)行膨脹操作,則當(dāng)前線程就進(jìn)行自旋等待鎖膨脹完成,這里需要注意一點(diǎn),雖然是自旋操作,但不會(huì)一直占用cpu資源,每隔一段時(shí)間會(huì)通過(guò)os::NakedYield方法放棄cpu資源,或通過(guò)park方法掛起;如果其他線程完成鎖的膨脹操作,則退出自旋并返回;5、如果當(dāng)前是輕量級(jí)鎖狀態(tài),即鎖標(biāo)識(shí)位為 00,膨脹過(guò)程如下:
1、通過(guò)omAlloc方法,獲取一個(gè)可用的ObjectMonitor monitor,并重置monitor數(shù)據(jù);2、通過(guò)CAS嘗試將Mark Word設(shè)置為markOopDesc:INFLATING,標(biāo)識(shí)當(dāng)前鎖正在膨脹中,如果CAS失敗,說(shuō)明同一時(shí)刻其它線程已經(jīng)將Mark Word設(shè)置為markOopDesc:INFLATING,當(dāng)前線程進(jìn)行自旋等待膨脹完成;3、如果CAS成功,設(shè)置monitor的各個(gè)字段:_header、_owner和_object等,并返回;
monitor競(jìng)爭(zhēng)
當(dāng)鎖膨脹完成并返回對(duì)應(yīng)的monitor時(shí),并不表示該線程競(jìng)爭(zhēng)到了鎖,真正的鎖競(jìng)爭(zhēng)發(fā)生在ObjectMonitor::enter方法中。
1、通過(guò)CAS嘗試把monitor的_owner字段設(shè)置為當(dāng)前線程;2、如果設(shè)置之前的_owner指向當(dāng)前線程,說(shuō)明當(dāng)前線程再次進(jìn)入monitor,即重入鎖,執(zhí)行_recursions ++ ,記錄重入的次數(shù);3、如果之前的_owner指向的地址在當(dāng)前線程中,這種描述有點(diǎn)拗口,換一種說(shuō)法:之前_owner指向的BasicLock在當(dāng)前線程棧上,說(shuō)明當(dāng)前線程是第一次進(jìn)入該monitor,設(shè)置_recursions為1,_owner為當(dāng)前線程,該線程成功獲得鎖并返回;4、如果獲取鎖失敗,則等待鎖的釋放;
monitor等待
monitor競(jìng)爭(zhēng)失敗的線程,通過(guò)自旋執(zhí)行ObjectMonitor::EnterI方法等待鎖的釋放,EnterI方法的部分邏輯實(shí)現(xiàn)如下:
1、當(dāng)前線程被封裝成ObjectWaiter對(duì)象node,狀態(tài)設(shè)置成ObjectWaiter::TS_CXQ;2、在for循環(huán)中,通過(guò)CAS把node節(jié)點(diǎn)push到_cxq列表中,同一時(shí)刻可能有多個(gè)線程把自己的node節(jié)點(diǎn)push到_cxq列表中;3、node節(jié)點(diǎn)push到_cxq列表之后,通過(guò)自旋嘗試獲取鎖,如果還是沒(méi)有獲取到鎖,則通過(guò)park將當(dāng)前線程掛起,等待被喚醒,實(shí)現(xiàn)如下:
4、當(dāng)該線程被喚醒時(shí),會(huì)從掛起的點(diǎn)繼續(xù)執(zhí)行,通過(guò)ObjectMonitor::TryLock嘗試獲取鎖,TryLock方法實(shí)現(xiàn)如下:
其本質(zhì)就是通過(guò)CAS設(shè)置monitor的_owner字段為當(dāng)前線程,如果CAS成功,則表示該線程獲取了鎖,跳出自旋操作,執(zhí)行同步代碼,否則繼續(xù)被掛起;
monitor釋放
當(dāng)某個(gè)持有鎖的線程執(zhí)行完同步代碼塊時(shí),會(huì)進(jìn)行鎖的釋放,給其它線程機(jī)會(huì)執(zhí)行同步代碼,在HotSpot中,通過(guò)退出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),通過(guò)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的競(jìng)爭(zhēng);
總結(jié)到此這篇關(guān)于Java同步關(guān)鍵字synchronize底層實(shí)現(xiàn)原理解析的文章就介紹到這了,更多相關(guān)java synchronize底層實(shí)現(xiàn)原理內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)!
相關(guān)文章:
1. AJAX實(shí)現(xiàn)省市縣三級(jí)聯(lián)動(dòng)效果2. Java通俗易懂系列設(shè)計(jì)模式之模板模式3. SpringBoot+SpringCache實(shí)現(xiàn)兩級(jí)緩存(Redis+Caffeine)4. ASP.NET MVC視圖頁(yè)使用jQuery傳遞異步數(shù)據(jù)的幾種方式詳解5. HTML <!DOCTYPE> 標(biāo)簽6. Java基于redis和mysql實(shí)現(xiàn)簡(jiǎn)單的秒殺(附demo)7. IDEA SpringBoot 項(xiàng)目配置Swagger2的詳細(xì)教程8. 如何用python識(shí)別滑塊驗(yàn)證碼中的缺口9. Kotlin + Flow 實(shí)現(xiàn)Android 應(yīng)用初始化任務(wù)啟動(dòng)庫(kù)10. php讀取xml中某個(gè)元素的內(nèi)容(PHP5以上才支持)
