Java的volatile和sychronized底層實(shí)現(xiàn)原理解析
1. 概覽
從Java代碼級(jí)別到硬件級(jí)別各層都是如何實(shí)現(xiàn)的
2. Synchronized
2.1 字節(jié)碼層面
使用javap -verbose <class文件>
可以查看到字節(jié)碼信息,其中synchronized方法會(huì)有flags:ACC_SYNCHRONIZED,此時(shí)字節(jié)碼中不會(huì)包含monitorenter和moniotrexit,JVM會(huì)自動(dòng)加
public synchronized void syncMethod(); flags: ACC_PUBLIC, ACC_SYNCHRONIZED
使用``javap -verbose <class文件>`編譯一個(gè)帶synchronized塊的代碼可以看到字節(jié)碼中的monitorenter和moniotrexit
0: new #2 // 創(chuàng)建一個(gè)新的Object實(shí)例 3: dup 4: invokespecial #1 // 調(diào)用Object的構(gòu)造函數(shù) 7: astore_1 // 將引用存儲(chǔ)到局部變量1(lock) 8: aload_1 // 將局部變量1(lock)加載到操作數(shù)棧 9: monitorenter // 進(jìn)入monitor 10: ... // 同步塊體的字節(jié)碼 : aload_1 : monitorexit // 退出monitor : ...
2.2 JVM層面
源碼可以在Github上面查看
monitorenter底層是由JVM的代碼ObjectMonitor來實(shí)現(xiàn)的
ObjectMonitor() { // 多線程競(jìng)爭(zhēng)鎖進(jìn)入時(shí)的單向鏈表 ObjectWaiter * volatile _cxq; //處于等待鎖block狀態(tài)的線程,會(huì)被加入到該列表 ObjectWaiter * volatile _EntryList; // _header是一個(gè)markOop類型,markOop就是對(duì)象頭中的Mark Word volatile markOop _header; // 搶占該鎖的線程數(shù),約等于WaitSet.size + EntryList.size volatile intptr_t _count; // 等待線程數(shù) volatile intptr_t _waiters; // 鎖的重入次數(shù) volatile intptr_ _recursions; // 監(jiān)視器鎖寄生的對(duì)象,鎖是寄托存儲(chǔ)于對(duì)象中 void* volatile _object; // 指向持有ObjectMonitor對(duì)象的線程 void* volatile _owner; // 處于wait狀態(tài)的線程,會(huì)被加入到_WaitSet ObjectWaiter * volatile _WaitSet; // 操作WaitSet鏈表的鎖 volatile int _WaitSetLock; // 嵌套加鎖次數(shù),最外層鎖的_recursions屬性為0 volatile intptr_t _recursions; }
2.2.1 enter方法
整個(gè)方法比較長(zhǎng),但我們了解的無鎖、偏向鎖、輕量級(jí)鎖、重量級(jí)鎖都可以看到,核心方法是Atomic::cmpxchg_ptr,這個(gè)是CAS操作
鎖 | 方法 | 描述 |
---|---|---|
偏向鎖 | Atomic::cmpxchg_ptr | 將owner替換為當(dāng)前線程,成功則獲取到鎖 |
輕量級(jí)鎖 | TrySpin->Atomic::cmpxchg_ptr | 不斷自旋將owner替換為當(dāng)前線程,成功則獲取到鎖 |
重量級(jí)鎖 | EnterI>Atomic::cmpxchg_ptr | park然后將owner替換為當(dāng)前線程,成功則獲取到鎖 |
void ATTR ObjectMonitor::enter(TRAPS) { // The following code is ordered to check the most common cases first // and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors. Thread * const Self = THREAD ; void * cur ; // 無鎖CAS 轉(zhuǎn)為 偏向鎖 cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ; if (cur == NULL) { // Either ASSERT _recursions == 0 or explicitly set _recursions = 0. assert (_recursions == 0 , "invariant") ; assert (_owner == Self, "invariant") ; // CONSIDER: set or assert OwnerIsThread == 1 return ; } // 可重入鎖 if (cur == Self) { // TODO-FIXME: check for integer overflow! BUGID 6557169. _recursions ++ ; return ; } if (Self->is_lock_owned ((address)cur)) { assert (_recursions == 0, "internal state error"); _recursions = 1 ; // Commute owner from a thread-specific on-stack BasicLockObject address to // a full-fledged "Thread *". _owner = Self ; OwnerIsThread = 1 ; return ; } // We've encountered genuine contention. assert (Self->_Stalled == 0, "invariant") ; Self->_Stalled = intptr_t(this) ; // Try one round of spinning *before* enqueueing Self // and before going through the awkward and expensive state // transitions. The following spin is strictly optional ... // Note that if we acquire the monitor from an initial spin // we forgo posting JVMTI events and firing DTRACE probes. // 自旋獲取鎖 if (Knob_SpinEarly && TrySpin (Self) > 0) { assert (_owner == Self , "invariant") ; assert (_recursions == 0 , "invariant") ; assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ; Self->_Stalled = 0 ; return ; } assert (_owner != Self , "invariant") ; assert (_succ != Self , "invariant") ; assert (Self->is_Java_thread() , "invariant") ; JavaThread * jt = (JavaThread *) Self ; assert (!SafepointSynchronize::is_at_safepoint(), "invariant") ; assert (jt->thread_state() != _thread_blocked , "invariant") ; assert (this->object() != NULL , "invariant") ; assert (_count >= 0, "invariant") ; // Prevent deflation at STW-time. See deflate_idle_monitors() and is_busy(). // Ensure the object-monitor relationship remains stable while there's contention. Atomic::inc_ptr(&_count); EventJavaMonitorEnter event; { // Change java thread status to indicate blocked on monitor enter. JavaThreadBlockedOnMonitorEnterState jtbmes(jt, this); DTRACE_MONITOR_PROBE(contended__enter, this, object(), jt); if (JvmtiExport::should_post_monitor_contended_enter()) { JvmtiExport::post_monitor_contended_enter(jt, this); } OSThreadContendState osts(Self->osthread()); ThreadBlockInVM tbivm(jt); Self->set_current_pending_monitor(this); // TODO-FIXME: change the following for(;;) loop to straight-line code. for (;;) { jt->set_suspend_equivalent(); // cleared by handle_special_suspend_equivalent_condition() // or java_suspend_self() // 重量級(jí)鎖 EnterI (THREAD) ; 省略....... }
2.2.2 cmpxchg_ptr
上面的鎖都用了這個(gè)方法cmpxchg_ptr,這個(gè)和java中的cas是類似的,那它又是怎么實(shí)現(xiàn)的呢
其中cmpxchg是Linux操作系統(tǒng)的函數(shù),執(zhí)行了一段匯編指令,并且有l(wèi)ock前綴
// 多核心多cpu前面就要加lock #define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: " inline intptr_t Atomic::cmpxchg_ptr(intptr_t exchange_value, volatile intptr_t* dest, intptr_t compare_value) { return (intptr_t)cmpxchg((jlong)exchange_value, (volatile jlong*)dest, (jlong)compare_value); } inline jlong Atomic::cmpxchg (jlong exchange_value, volatile jlong* dest, jlong compare_value) { bool mp = os::is_MP(); __asm__ __volatile__ (LOCK_IF_MP(%4) "cmpxchgq %1,(%3)" : "=a" (exchange_value) : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp) : "cc", "memory"); return exchange_value; }
3. Volatile
3.1 字節(jié)碼層面
static volatile int greaterThanSevenCnt; descriptor: I flags: ACC_STATIC, ACC_VOLATILE
3.2 JVM層面
可以看到判斷是否是volatile字段,是的話最后會(huì)有OrderAccess::storeload();
, 就是就是storeload屏障
CASE(_putfield): CASE(_putstatic): { // .... 省略若干行 // .... // Now store the result 現(xiàn)在要開始存儲(chǔ)結(jié)果了 // ConstantPoolCacheEntry* cache; -- cache是常量池緩存實(shí)例 // cache->is_volatile() -- 判斷是否有volatile訪問標(biāo)志修飾 int field_offset = cache->f2_as_index(); if (cache->is_volatile()) { // ****重點(diǎn)判斷邏輯**** // volatile變量的賦值邏輯 if (tos_type == itos) { obj->release_int_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == atos) {// 對(duì)象類型賦值 VERIFY_OOP(STACK_OBJECT(-1)); obj->release_obj_field_put(field_offset, STACK_OBJECT(-1)); OrderAccess::release_store(&BYTE_MAP_BASE[(uintptr_t)obj >> CardTableModRefBS::card_shift], 0); } else if (tos_type == btos) {// byte類型賦值 obj->release_byte_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == ltos) {// long類型賦值 obj->release_long_field_put(field_offset, STACK_LONG(-1)); } else if (tos_type == ctos) {// char類型賦值 obj->release_char_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == stos) {// short類型賦值 obj->release_short_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == ftos) {// float類型賦值 obj->release_float_field_put(field_offset, STACK_FLOAT(-1)); } else {// double類型賦值 obj->release_double_field_put(field_offset, STACK_DOUBLE(-1)); } // *** 寫完值后的storeload屏障 *** OrderAccess::storeload(); } else { // 非volatile變量的賦值邏輯 if (tos_type == itos) { obj->int_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == atos) { VERIFY_OOP(STACK_OBJECT(-1)); obj->obj_field_put(field_offset, STACK_OBJECT(-1)); OrderAccess::release_store(&BYTE_MAP_BASE[(uintptr_t)obj >> CardTableModRefBS::card_shift], 0); } else if (tos_type == btos) { obj->byte_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == ltos) { obj->long_field_put(field_offset, STACK_LONG(-1)); } else if (tos_type == ctos) { obj->char_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == stos) { obj->short_field_put(field_offset, STACK_INT(-1)); } else if (tos_type == ftos) { obj->float_field_put(field_offset, STACK_FLOAT(-1)); } else { obj->double_field_put(field_offset, STACK_DOUBLE(-1)); } } UPDATE_PC_AND_TOS_AND_CONTINUE(3, count); }
進(jìn)入OrderAccess源碼可以看到,直接執(zhí)行了一段匯編指令,并且有l(wèi)ock前綴
inline void OrderAccess::storeload() { fence(); } inline void OrderAccess::fence() { if (os::is_MP()) { // always use locked addl since mfence is sometimes expensive #ifdef AMD64 __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory"); #else __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory"); #endif } }
4. lock指令
在上面的分析中,最底層都設(shè)計(jì)到匯編層面的lock指令,這個(gè)指令有什么作用呢?
根據(jù)匯編參考文檔IA-32 Assembly Language Reference Manual
The LOCK # signal is asserted during execution of the instruction following the lock prefix. This signal can be used in a multiprocessor system to ensure exclusive use of shared memory while LOCK # is asserted. The bts instruction is the read-modify-write sequence used to implement test-and-run. The lock prefix works only with the instructions listed here. If a lock prefix is used with any other instructions, an undefined opcode trap is generated.
Lock是一個(gè)指令前綴,用于多核處理器系統(tǒng)不使用共享內(nèi)存
那么它又是怎么讓其他核心不訪問共享內(nèi)存,有兩種方法
- 鎖內(nèi)存總線,也就是說執(zhí)行這條指令的時(shí)候,其他的核心都不能在訪問內(nèi)存了
- 鎖緩存行,現(xiàn)在CPU本身是有多級(jí)緩存的,而這些緩存是如何保持一致的,由MESI來支持,MESI協(xié)議可以保證其他核心不使用內(nèi)存,或者換一種說法,可以使用,但被修改的內(nèi)容會(huì)失效
5. MESI協(xié)議
現(xiàn)代CPU多核架構(gòu)中為了協(xié)調(diào)快速的CPU運(yùn)算和相對(duì)較慢的內(nèi)存讀寫速度之間的矛盾,在CPU和內(nèi)存之間引入了CPU cache:
MESI協(xié)議下,緩存行(cache line)有四種狀態(tài)來保證緩存的一致性
- 已修改Modified (M) 緩存行是臟的,與主存的值不同。如果別的CPU內(nèi)核要讀主存這塊數(shù)據(jù),該緩存行必須回寫到主存,狀態(tài)變?yōu)楣蚕?S)
- 獨(dú)占Exclusive (E) 緩存行只在當(dāng)前緩存中,但是干凈的(clean)–緩存數(shù)據(jù)同于主存數(shù)據(jù)。當(dāng)別的緩存讀取它時(shí),狀態(tài)變?yōu)楣蚕恚划?dāng)前寫數(shù)據(jù)時(shí),變?yōu)橐研薷臓顟B(tài)。
- 共享Shared (S) 緩存行也存在于其它緩存中且是干凈的。緩存行可以在任意時(shí)刻拋棄。
- 無效Invalid (I) 緩存行是無效的,需要從主內(nèi)存中讀取最新值
每次要修改緩存,如果緩存行狀態(tài)為 S 的話都要先發(fā)一個(gè) invalidate 的廣播,再等其他 CPU 將緩存行設(shè)置為無效后返回 invalidate ack 才能寫到 Cache 中,因?yàn)檫@樣才能保證緩存的一致性
但是如果 CPU 頻繁地修改數(shù)據(jù),就會(huì)不斷地發(fā)送廣播消息,CPU 只能被動(dòng)同步地等待其他 CPU 的消息,顯然會(huì)對(duì)執(zhí)行效率產(chǎn)生影響
為了解決此問題,工程師在 CPU 和 cache 之間又加了一個(gè) store buffer,同時(shí)在cache和總線之間添加了Invalidate Queue
這個(gè)buffer可以讓廣播和收廣播的處理異步化,效率當(dāng)然會(huì)變高,但強(qiáng)一致性變?yōu)榱俗罱K一致性
lock指令是CPU硬件工程師給程序員留的一個(gè)口子,把對(duì)MESI協(xié)議的優(yōu)化(store buffer, invalidate queue)禁用,暫時(shí)以同步方式工作,使得對(duì)于該關(guān)鍵字的MESI協(xié)議退回強(qiáng)一致性狀態(tài)
6. 總結(jié)
分析到此:
所有的并發(fā)問題可以概括為,多個(gè)核心同時(shí)修改內(nèi)存數(shù)據(jù),導(dǎo)致結(jié)果不符合預(yù)期
解決并發(fā)問題的方法可以概括為,同一時(shí)間只能讓一個(gè)核心修改內(nèi)存,但有多種手段,例如鎖總線、或者廣播讓其他核心失效
7. 其他問題
既然sychronized的和volatile底層實(shí)現(xiàn)是一樣的,那么volatile為什么沒有原子性呢?
在于鎖定的范圍,volatile修飾的是一個(gè)字段,只能保證讀和寫是原子性的,但讀出來、在計(jì)算、寫入分為三步則不是原子性的。
sychronized底層也用了volatile的,但它的鎖定范圍是程序員指定的,這個(gè)范圍之間的代碼是原子的
cas volatile變量開始鎖定 任意程序代碼 cas volatile變量釋放鎖定
現(xiàn)在一般推薦使用Java的Atomic類,他是通過CAS來實(shí)現(xiàn)的,它和sychronized的區(qū)別是什么?
cas不能單獨(dú)使用,需要加自旋操作,本身是一個(gè)樂觀鎖
sychronized本身結(jié)合了樂觀鎖和悲觀鎖,悲觀鎖會(huì)讓線程park然后重試,不會(huì)消耗CPU,而樂觀鎖但不斷消耗cpu
8. 對(duì)比
在閱讀ObjectMonitor代碼時(shí),發(fā)現(xiàn)有很熟悉的感覺
發(fā)現(xiàn)這些鎖的數(shù)據(jù)結(jié)果都是類似的,一個(gè)volatile變量加一個(gè)等待隊(duì)列
參考
【1】]synchronized 關(guān)鍵字底層原理
【2】Java多線程:objectMonitor源碼解讀(3)
【3】Linux Kernel CMPXCHG函數(shù)分析
【4】聊聊CPU的LOCK指令
【5】12 張圖看懂 CPU 緩存一致性與 MESI 協(xié)議,真的一致嗎?
【9】CAS你以為你真的懂?
【10】x86 LOCK 指令前綴
到此這篇關(guān)于Java的volatile和sychronized底層實(shí)現(xiàn)原理解析的文章就介紹到這了,更多相關(guān)Java volatile和sychronized底層內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
java web response提供文件下載功能的實(shí)例講解
下面小編就為大家分享一篇java web response提供文件下載功能的實(shí)例講解,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2018-01-01SpringCloud集成sleuth和zipkin實(shí)現(xiàn)微服務(wù)鏈路追蹤的實(shí)戰(zhàn)分享
最近項(xiàng)目上準(zhǔn)備引入接口調(diào)用鏈路追蹤,說到這個(gè)我們就不得不想到springcloud全家桶中的sleuth了,他可以將跨多個(gè)服務(wù)請(qǐng)求鏈路記錄下來,供我們查詢分析,所以今天就分享一期微服務(wù)架構(gòu)接入sleuth+zipkin實(shí)戰(zhàn)演示,需要的朋友可以參考下2024-12-12Spring Boot的listener(監(jiān)聽器)簡(jiǎn)單使用實(shí)例詳解
監(jiān)聽器(Listener)的注冊(cè)方法和 Servlet 一樣,有兩種方式:代碼注冊(cè)或者注解注冊(cè)。接下來通過本文給大家介紹Spring Boot的listener(監(jiān)聽器)簡(jiǎn)單使用,需要的朋友可以參考下2017-04-04SpringCloud服務(wù)之間Feign調(diào)用不會(huì)帶上請(qǐng)求頭header的解決方法
在Spring?Cloud中,使用Feign進(jìn)行服務(wù)之間的調(diào)用時(shí),默認(rèn)情況下是不會(huì)傳遞header的,這篇文章給大家介紹SpringCloud服務(wù)之間Feign調(diào)用不會(huì)帶上請(qǐng)求頭header的解決方法,感興趣的朋友一起看看吧2024-01-01高并發(fā)環(huán)境下安全修改同一行數(shù)據(jù)庫數(shù)據(jù)的策略分享
隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展,越來越多的應(yīng)用需要在高并發(fā)環(huán)境中運(yùn)行,數(shù)據(jù)庫的并發(fā)控制成為了業(yè)務(wù)的關(guān)鍵,本文將介紹如何在高并發(fā)情況下,安全地修改數(shù)據(jù)庫中的同一行數(shù)據(jù),需要的可以參考一下2023-06-06JAVA內(nèi)存空間相關(guān)知識(shí)匯總
這篇文章主要介紹了JAVA內(nèi)存空間相關(guān)知識(shí),文中介紹的非常詳細(xì),代碼幫助大家更好的參考和學(xué)習(xí),感興趣的朋友可以了解下2020-06-06java普通項(xiàng)目讀取不到resources目錄下資源文件的解決辦法
這篇文章主要給大家介紹了關(guān)于java普通項(xiàng)目讀取不到resources目錄下資源文件的解決辦法,Web項(xiàng)目中應(yīng)該經(jīng)常有這樣的需求,在maven項(xiàng)目的resources目錄下放一些文件,比如一些配置文件,資源文件等,需要的朋友可以參考下2023-09-09