溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

發(fā)布時(shí)間:2020-10-05 16:38:21 來(lái)源:腳本之家 閱讀:178 作者:五月的倉(cāng)頡 欄目:編程語(yǔ)言

前言

我們知道volatile關(guān)鍵字的作用是保證變量在多線程之間的可見(jiàn)性,它是java.util.concurrent包的核心,沒(méi)有volatile就沒(méi)有這么多的并發(fā)類給我們使用。

本文詳細(xì)解讀一下volatile關(guān)鍵字如何保證變量在多線程之間的可見(jiàn)性,在此之前,有必要講解一下CPU緩存的相關(guān)知識(shí),掌握這部分知識(shí)一定會(huì)讓我們更好地理解volatile的原理,從而更好、更正確地地使用volatile關(guān)鍵字。

CPU緩存

CPU緩存的出現(xiàn)主要是為了解決CPU運(yùn)算速度與內(nèi)存讀寫(xiě)速度不匹配的矛盾,因?yàn)镃PU運(yùn)算速度要比內(nèi)存讀寫(xiě)速度快得多,舉個(gè)例子:

  • 一次主內(nèi)存的訪問(wèn)通常在幾十到幾百個(gè)時(shí)鐘周期
  • 一次L1高速緩存的讀寫(xiě)只需要1~2個(gè)時(shí)鐘周期
  • 一次L2高速緩存的讀寫(xiě)也只需要數(shù)十個(gè)時(shí)鐘周期

這種訪問(wèn)速度的顯著差異,導(dǎo)致CPU可能會(huì)花費(fèi)很長(zhǎng)時(shí)間等待數(shù)據(jù)到來(lái)或把數(shù)據(jù)寫(xiě)入內(nèi)存。

基于此,現(xiàn)在CPU大多數(shù)情況下讀寫(xiě)都不會(huì)直接訪問(wèn)內(nèi)存(CPU都沒(méi)有連接到內(nèi)存的管腳),取而代之的是CPU緩存,CPU緩存是位于CPU與內(nèi)存之間的臨時(shí)存儲(chǔ)器,它的容量比內(nèi)存小得多但是交換速度卻比內(nèi)存快得多。而緩存中的數(shù)據(jù)是內(nèi)存中的一小部分?jǐn)?shù)據(jù),但這一小部分是短時(shí)間內(nèi)CPU即將訪問(wèn)的,當(dāng)CPU調(diào)用大量數(shù)據(jù)時(shí),就可先從緩存中讀取,從而加快讀取速度。

按照讀取順序與CPU結(jié)合的緊密程度,CPU緩存可分為:

  • 一級(jí)緩存:簡(jiǎn)稱L1 Cache,位于CPU內(nèi)核的旁邊,是與CPU結(jié)合最為緊密的CPU緩存
  • 二級(jí)緩存:簡(jiǎn)稱L2 Cache,分內(nèi)部和外部?jī)煞N芯片,內(nèi)部芯片二級(jí)緩存運(yùn)行速度與主頻相同,外部芯片二級(jí)緩存運(yùn)行速度則只有主頻的一半
  • 三級(jí)緩存:簡(jiǎn)稱L3 Cache,部分高端CPU才有

每一級(jí)緩存中所存儲(chǔ)的數(shù)據(jù)全部都是下一級(jí)緩存中的一部分,這三種緩存的技術(shù)難度和制造成本是相對(duì)遞減的,所以其容量也相對(duì)遞增。

當(dāng)CPU要讀取一個(gè)數(shù)據(jù)時(shí),首先從一級(jí)緩存中查找,如果沒(méi)有再?gòu)亩?jí)緩存中查找,如果還是沒(méi)有再?gòu)娜?jí)緩存中或內(nèi)存中查找。一般來(lái)說(shuō)每級(jí)緩存的命中率大概都有80%左右,也就是說(shuō)全部數(shù)據(jù)量的80%都可以在一級(jí)緩存中找到,只剩下20%的總數(shù)據(jù)量才需要從二級(jí)緩存、三級(jí)緩存或內(nèi)存中讀取。

使用CPU緩存帶來(lái)的問(wèn)題

用一張圖表示一下CPU-->CPU緩存-->主內(nèi)存數(shù)據(jù)讀取之間的關(guān)系:

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

當(dāng)系統(tǒng)運(yùn)行時(shí),CPU執(zhí)行計(jì)算的過(guò)程如下:

  1. 程序以及數(shù)據(jù)被加載到主內(nèi)存
  2. 指令和數(shù)據(jù)被加載到CPU緩存
  3. CPU執(zhí)行指令,把結(jié)果寫(xiě)到高速緩存
  4. 高速緩存中的數(shù)據(jù)寫(xiě)回主內(nèi)存

如果服務(wù)器是單核CPU,那么這些步驟不會(huì)有任何的問(wèn)題,但是如果服務(wù)器是多核CPU,那么問(wèn)題來(lái)了,以Intel Core i7處理器的高速緩存概念模型為例(圖片摘自《深入理解計(jì)算機(jī)系統(tǒng)》):

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

試想下面一種情況:

  1. 核0讀取了一個(gè)字節(jié),根據(jù)局部性原理,它相鄰的字節(jié)同樣被被讀入核0的緩存
  2. 核3做了上面同樣的工作,這樣核0與核3的緩存擁有同樣的數(shù)據(jù)
  3. 核0修改了那個(gè)字節(jié),被修改后,那個(gè)字節(jié)被寫(xiě)回核0的緩存,但是該信息并沒(méi)有寫(xiě)回主存
  4. 核3訪問(wèn)該字節(jié),由于核0并未將數(shù)據(jù)寫(xiě)回主存,數(shù)據(jù)不同步

為了解決這個(gè)問(wèn)題,CPU制造商制定了一個(gè)規(guī)則:當(dāng)一個(gè)CPU修改緩存中的字節(jié)時(shí),服務(wù)器中其他CPU會(huì)被通知,它們的緩存將視為無(wú)效。于是,在上面的情況下,核3發(fā)現(xiàn)自己的緩存中數(shù)據(jù)已無(wú)效,核0將立即把自己的數(shù)據(jù)寫(xiě)回主存,然后核3重新讀取該數(shù)據(jù)。

可以看出,緩存在多核CPU的使用情況下會(huì)有一些性能的缺失。

反匯編Java字節(jié)碼,查看匯編層面對(duì)volatile關(guān)鍵字做了什么

有了上面的理論基礎(chǔ),我們可以研究volatile關(guān)鍵字到底是如何實(shí)現(xiàn)的。首先寫(xiě)一段簡(jiǎn)單的代碼:

/** * @author 五月的倉(cāng)頡http://www.cnblogs.com/xrq730/p/7048693.html
 */
public class LazySingleton {
  private static volatile LazySingleton instance = null;
  public static LazySingleton getInstance() {
    if (instance == null) {
      instance = new LazySingleton();
    }
    return instance;
  }
  public static void main(String[] args) {
    LazySingleton.getInstance();
  }
}

首先反編譯一下這段代碼的.class文件,看一下生成的字節(jié)碼:

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

沒(méi)有任何特別的。我們知道,字節(jié)碼指令,比如上圖的getstatic、ifnonnull、new等,最終對(duì)應(yīng)到操作系統(tǒng)的層面,都是轉(zhuǎn)換為一條一條指令去執(zhí)行,我們使用的PC機(jī)、應(yīng)用服務(wù)器的CPU架構(gòu)通常都是IA-32架構(gòu)的,這種架構(gòu)采用的指令集是CISC(復(fù)雜指令集),而匯編語(yǔ)言則是這種指令集的助記符。

因此,既然在字節(jié)碼層面我們看不出什么端倪,那下面就看看將代碼轉(zhuǎn)換為匯編指令能看出什么端倪。Windows上要看到以上代碼對(duì)應(yīng)的匯編碼不難(吐槽一句,說(shuō)說(shuō)不難,為了這個(gè)問(wèn)題我找遍了各種資料,差點(diǎn)就準(zhǔn)備安裝虛擬機(jī),在Linux系統(tǒng)上搞了),訪問(wèn)hsdis工具路徑可直接下載hsdis工具,下載完畢之后解壓,將hsdis-amd64.dll與hsdis-amd64.lib兩個(gè)文件放在%JAVA_HOME%\jre\bin\server路徑下即可,如下圖:

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

然后跑main函數(shù),跑main函數(shù)之前,加入如下虛擬機(jī)參數(shù):

-server -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*LazySingleton.getInstance

運(yùn)行main函數(shù)即可,代碼生成的匯編指令為:

Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output
CompilerOracle: compileonly *LazySingleton.getInstance
Loaded disassembler from D:\JDK\jre\bin\server\hsdis-amd64.dll
Decoding compiled method 0x0000000002931150:
Code:
Argument 0 is unknown.RIP: 0x29312a0 Code size: 0x00000108
[Disassembling for mach='amd64']
[Entry Point]
[Verified Entry Point]
[Constants]
 # {method} 'getInstance' '()Lorg/xrq/test/design/singleton/LazySingleton;' in 'org/xrq/test/design/singleton/LazySingleton'
 #      [sp+0x20] (sp of caller)
 0x00000000029312a0: mov   dword ptr [rsp+0ffffffffffffa000h],eax
 0x00000000029312a7: push  rbp
 0x00000000029312a8: sub   rsp,10h      ;*synchronization entry
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@-1 (line 13)
 0x00000000029312ac: mov   r10,7ada9e428h  ;  {oop(a 'java/lang/Class' = 'org/xrq/test/design/singleton/LazySingleton')}
 0x00000000029312b6: mov   r11d,dword ptr [r10+58h]
                        ;*getstatic instance
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@0 (line 13)
 0x00000000029312ba: test  r11d,r11d
 0x00000000029312bd: je   29312e0h
 0x00000000029312bf: mov   r10,7ada9e428h  ;  {oop(a 'java/lang/Class' = 'org/xrq/test/design/singleton/LazySingleton')}
 0x00000000029312c9: mov   r11d,dword ptr [r10+58h]
 0x00000000029312cd: mov   rax,r11
 0x00000000029312d0: shl   rax,3h      ;*getstatic instance
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@16 (line 17)
 0x00000000029312d4: add   rsp,10h
 0x00000000029312d8: pop   rbp
 0x00000000029312d9: test  dword ptr [330000h],eax ;  {poll_return}
 0x00000000029312df: ret
 0x00000000029312e0: mov   rax,qword ptr [r15+60h]
 0x00000000029312e4: mov   r10,rax
 0x00000000029312e7: add   r10,10h
 0x00000000029312eb: cmp   r10,qword ptr [r15+70h]
 0x00000000029312ef: jnb   293135bh
 0x00000000029312f1: mov   qword ptr [r15+60h],r10
 0x00000000029312f5: prefetchnta byte ptr [r10+0c0h]
 0x00000000029312fd: mov   r11d,0e07d00b2h  ;  {oop('org/xrq/test/design/singleton/LazySingleton')}
 0x0000000002931303: mov   r10,qword ptr [r12+r11*8+0b0h]
 0x000000000293130b: mov   qword ptr [rax],r10
 0x000000000293130e: mov   dword ptr [rax+8h],0e07d00b2h
                        ;  {oop('org/xrq/test/design/singleton/LazySingleton')}
 0x0000000002931315: mov   dword ptr [rax+0ch],r12d
 0x0000000002931319: mov   rbp,rax      ;*new ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
 0x000000000293131c: mov   rdx,rbp
 0x000000000293131f: call  2907c60h     ; OopMap{rbp=Oop off=132}
                        ;*invokespecial <init>
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@10 (line 14)
                        ;  {optimized virtual_call}
 0x0000000002931324: mov   r10,rbp
 0x0000000002931327: shr   r10,3h
 0x000000000293132b: mov   r11,7ada9e428h  ;  {oop(a 'java/lang/Class' = 'org/xrq/test/design/singleton/LazySingleton')}
 0x0000000002931335: mov   dword ptr [r11+58h],r10d
 0x0000000002931339: mov   r10,7ada9e428h  ;  {oop(a 'java/lang/Class' = 'org/xrq/test/design/singleton/LazySingleton')}
 0x0000000002931343: shr   r10,9h
 0x0000000002931347: mov   r11d,20b2000h
 0x000000000293134d: mov   byte ptr [r11+r10],r12l
 0x0000000002931351: lock add dword ptr [rsp],0h ;*putstatic instance
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@13 (line 14)
 0x0000000002931356: jmp   29312bfh
 0x000000000293135b: mov   rdx,703e80590h  ;  {oop('org/xrq/test/design/singleton/LazySingleton')}
 0x0000000002931365: nop
 0x0000000002931367: call  292fbe0h     ; OopMap{off=204}
                        ;*new ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
                        ;  {runtime_call}
 0x000000000293136c: jmp   2931319h
 0x000000000293136e: mov   rdx,rax
 0x0000000002931371: jmp   2931376h
 0x0000000002931373: mov   rdx,rax      ;*new ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
 0x0000000002931376: add   rsp,10h
 0x000000000293137a: pop   rbp
 0x000000000293137b: jmp   2932b20h     ;  {runtime_call}
[Stub Code]
 0x0000000002931380: mov   rbx,0h      ;  {no_reloc}
 0x000000000293138a: jmp   293138ah     ;  {runtime_call}
[Exception Handler]
 0x000000000293138f: jmp   292fca0h     ;  {runtime_call}
[Deopt Handler Code]
 0x0000000002931394: call  2931399h
 0x0000000002931399: sub   qword ptr [rsp],5h
 0x000000000293139e: jmp   2909000h     ;  {runtime_call}
 0x00000000029313a3: hlt
 0x00000000029313a4: hlt
 0x00000000029313a5: hlt
 0x00000000029313a6: hlt
 0x00000000029313a7: hlt

這么長(zhǎng)長(zhǎng)的匯編代碼,可能大家不知道CPU在哪里做了手腳,沒(méi)事不難,定位到59、60兩行:

0x0000000002931351: lock add dword ptr [rsp],0h ;*putstatic instance
                        ; - org.xrq.test.design.singleton.LazySingleton::getInstance@13 (line 14)

之所以定位到這兩行是因?yàn)檫@里結(jié)尾寫(xiě)明了line 14,line 14即volatile變量instance賦值的地方。后面的add dword ptr [rsp],0h都是正常的匯編語(yǔ)句,意思是將雙字節(jié)的棧指針寄存器+0,這里的關(guān)鍵就是add前面的lock指令,后面詳細(xì)分析一下lock指令的作用和為什么加上lock指令后就能保證volatile關(guān)鍵字的內(nèi)存可見(jiàn)性。

lock指令做了什么

之前有說(shuō)過(guò)IA-32架構(gòu),關(guān)于CPU架構(gòu)的問(wèn)題大家有興趣的可以自己查詢一下,這里查詢一下IA-32手冊(cè)關(guān)于lock指令的描述,沒(méi)有IA-32手冊(cè)的可以去這個(gè)地址下載IA-32手冊(cè)下載地址,是個(gè)中文版本的手冊(cè)。

我摘抄一下IA-32手冊(cè)中關(guān)于lock指令作用的一些描述(因?yàn)閘ock指令的作用在手冊(cè)中散落在各處,并不是在某一章或者某一節(jié)專門(mén)講):

在修改內(nèi)存操作時(shí),使用LOCK前綴去調(diào)用加鎖的讀-修改-寫(xiě)操作,這種機(jī)制用于多處理器系統(tǒng)中處理器之間進(jìn)行可靠的通訊,具體描述如下:

(1)在Pentium和早期的IA-32處理器中,LOCK前綴會(huì)使處理器執(zhí)行當(dāng)前指令時(shí)產(chǎn)生一個(gè)LOCK#信號(hào),這種總是引起顯式總線鎖定出現(xiàn)

(2)在Pentium4、Inter Xeon和P6系列處理器中,加鎖操作是由高速緩存鎖或總線鎖來(lái)處理。如果內(nèi)存訪問(wèn)有高速緩存且只影響一個(gè)單獨(dú)的高速緩存行,那么操作中就會(huì)調(diào)用高速緩存鎖,而系統(tǒng)總線和系統(tǒng)內(nèi)存中的實(shí)際區(qū)域內(nèi)不會(huì)被鎖定。同時(shí),這條總線上的其它Pentium4、Intel Xeon或者P6系列處理器就回寫(xiě)所有已修改的數(shù)據(jù)并使它們的高速緩存失效,以保證系統(tǒng)內(nèi)存的一致性。如果內(nèi)存訪問(wèn)沒(méi)有高速緩存且/或它跨越了高速緩存行的邊界,那么這個(gè)處理器就會(huì)產(chǎn)生LOCK#信號(hào),并在鎖定操作期間不會(huì)響應(yīng)總線控制請(qǐng)求
32位IA-32處理器支持對(duì)系統(tǒng)內(nèi)存中的某個(gè)區(qū)域進(jìn)行加鎖的原子操作。這些操作常用來(lái)管理共享的數(shù)據(jù)結(jié)構(gòu)(如信號(hào)量、段描述符、系統(tǒng)段或頁(yè)表),兩個(gè)或多個(gè)處理器可能同時(shí)會(huì)修改這些數(shù)據(jù)結(jié)構(gòu)中的同一數(shù)據(jù)域或標(biāo)志。處理器使用三個(gè)相互依賴的機(jī)制來(lái)實(shí)現(xiàn)加鎖的原子操作:

1、保證原子操作

2、總線加鎖,使用LOCK#信號(hào)和LOCK指令前綴

3、高速緩存相干性協(xié)議,確保對(duì)高速緩存中的數(shù)據(jù)結(jié)構(gòu)執(zhí)行原子操作(高速緩存鎖)。這種機(jī)制存在于Pentium4、Intel Xeon和P6系列處理器中

IA-32處理器提供有一個(gè)LOCK#信號(hào),會(huì)在某些關(guān)鍵內(nèi)存操作期間被自動(dòng)激活,去鎖定系統(tǒng)總線。當(dāng)這個(gè)輸出信號(hào)發(fā)出的時(shí)候,來(lái)自其他處理器或總線代理的控制請(qǐng)求將被阻塞。軟件能夠通過(guò)預(yù)先在指令前添加LOCK前綴來(lái)指定需要LOCK語(yǔ)義的其它場(chǎng)合。

在Intel386、Intel486、Pentium處理器中,明確地對(duì)指令加鎖會(huì)導(dǎo)致LOCK#信號(hào)的產(chǎn)生。由硬件設(shè)計(jì)人員來(lái)保證系統(tǒng)硬件中LOCK#信號(hào)的可用性,以控制處理器間的內(nèi)存訪問(wèn)。

對(duì)于Pentinum4、Intel Xeon以及P6系列處理器,如果被訪問(wèn)的內(nèi)存區(qū)域是在處理器內(nèi)部進(jìn)行高速緩存的,那么通常不發(fā)出LOCK#信號(hào);相反,加鎖只應(yīng)用于處理器的高速緩存。

為顯式地強(qiáng)制執(zhí)行LOCK語(yǔ)義,軟件可以在下列指令修改內(nèi)存區(qū)域時(shí)使用LOCK前綴。當(dāng)LOCK前綴被置于其它指令之前或者指令沒(méi)有對(duì)內(nèi)存進(jìn)行寫(xiě)操作(也就是說(shuō)目標(biāo)操作數(shù)在寄存器中)時(shí),會(huì)產(chǎn)生一個(gè)非法操作碼異常(#UD)。

【1】位測(cè)試和修改指令(BTS、BTR、BTC)
【2】交換指令(XADD、CMPXCHG、CMPXCHG8B)
【3】自動(dòng)假設(shè)有LOCK前綴的XCHG指令
【4】下列單操作數(shù)的算數(shù)和邏輯指令:INC、DEC、NOT、NEG
【5】下列雙操作數(shù)的算數(shù)和邏輯指令:ADD、ADC、SUB、SBB、AND、OR、XOR
一個(gè)加鎖的指令會(huì)保證對(duì)目標(biāo)操作數(shù)所在的內(nèi)存區(qū)域加鎖,但是系統(tǒng)可能會(huì)將鎖定區(qū)域解釋得稍大一些。
軟件應(yīng)該使用相同的地址和操作數(shù)長(zhǎng)度來(lái)訪問(wèn)信號(hào)量(用作處理器之間發(fā)送信號(hào)的共享內(nèi)存)。例如,如果一個(gè)處理器使用一個(gè)字來(lái)訪問(wèn)信號(hào)量,其它處理器就不應(yīng)該使用一個(gè)字節(jié)來(lái)訪問(wèn)這個(gè)信號(hào)量。
總線鎖的完整性不收內(nèi)存區(qū)域?qū)R的影響。加鎖語(yǔ)義會(huì)一直持續(xù),以滿足更新整個(gè)操作數(shù)所需的總線周期個(gè)數(shù)。但是,建議加鎖訪問(wèn)應(yīng)該對(duì)齊在它們的自然邊界上,以提升系統(tǒng)性能:
【1】任何8位訪問(wèn)的邊界(加鎖或不加鎖)
【2】鎖定的字訪問(wèn)的16位邊界
【3】鎖定的雙字訪問(wèn)的32位邊界
【4】鎖定的四字訪問(wèn)的64位邊界
對(duì)所有其它的內(nèi)存操作和所有可見(jiàn)的外部事件來(lái)說(shuō),加鎖的操作都是原子的。所有取指令和頁(yè)表操作能夠越過(guò)加鎖的指令。加鎖的指令可用于同步一個(gè)處理器寫(xiě)數(shù)據(jù)而另一個(gè)處理器讀數(shù)據(jù)的操作。

IA-32架構(gòu)提供了幾種機(jī)制用來(lái)強(qiáng)化或弱化內(nèi)存排序模型,以處理特殊的編程情形。這些機(jī)制包括:

【1】I/O指令、加鎖指令、LOCK前綴以及串行化指令等,強(qiáng)制在處理器上進(jìn)行較強(qiáng)的排序

【2】SFENCE指令(在Pentium III中引入)和LFENCE指令、MFENCE指令(在Pentium4和Intel Xeon處理器中引入)提供了某些特殊類型內(nèi)存操作的排序和串行化功能
...(這里還有兩條就不寫(xiě)了)

這些機(jī)制可以通過(guò)下面的方式使用。

總線上的內(nèi)存映射設(shè)備和其它I/O設(shè)備通常對(duì)向它們緩沖區(qū)寫(xiě)操作的順序很敏感,I/O指令(IN指令和OUT指令)以下面的方式對(duì)這種訪問(wèn)執(zhí)行強(qiáng)寫(xiě)操作的排序。在執(zhí)行了一條I/O指令之前,處理器等待之前的所有指令執(zhí)行完畢以及所有的緩沖區(qū)都被都被寫(xiě)入了內(nèi)存。只有取指令和頁(yè)表查詢能夠越過(guò)I/O指令,后續(xù)指令要等到I/O指令執(zhí)行完畢才開(kāi)始執(zhí)行。

反復(fù)思考IA-32手冊(cè)對(duì)lock指令作用的這幾段描述,可以得出lock指令的幾個(gè)作用:

  1. 鎖總線,其它CPU對(duì)內(nèi)存的讀寫(xiě)請(qǐng)求都會(huì)被阻塞,直到鎖釋放,不過(guò)實(shí)際后來(lái)的處理器都采用鎖緩存替代鎖總線,因?yàn)殒i總線的開(kāi)銷比較大,鎖總線期間其他CPU沒(méi)法訪問(wèn)內(nèi)存
  2. lock后的寫(xiě)操作會(huì)回寫(xiě)已修改的數(shù)據(jù),同時(shí)讓其它CPU相關(guān)緩存行失效,從而重新從主存中加載最新的數(shù)據(jù)
  3. 不是內(nèi)存屏障卻能完成類似內(nèi)存屏障的功能,阻止屏障兩遍的指令重排序

(1)中寫(xiě)了由于效率問(wèn)題,實(shí)際后來(lái)的處理器都采用鎖緩存來(lái)替代鎖總線,這種場(chǎng)景下多緩存的數(shù)據(jù)一致是通過(guò)緩存一致性協(xié)議來(lái)保證的,我們來(lái)看一下什么是緩存一致性協(xié)議。

緩存一致性協(xié)議

講緩存一致性之前,先說(shuō)一下緩存行的概念:

緩存是分段(line)的,一個(gè)段對(duì)應(yīng)一塊存儲(chǔ)空間,我們稱之為緩存行,它是CPU緩存中可分配的最小存儲(chǔ)單元,大小32字節(jié)、64字節(jié)、128字節(jié)不等,這與CPU架構(gòu)有關(guān)。當(dāng)CPU看到一條讀取內(nèi)存的指令時(shí),它會(huì)把內(nèi)存地址傳遞給一級(jí)數(shù)據(jù)緩存,一級(jí)數(shù)據(jù)緩存會(huì)檢查它是否有這個(gè)內(nèi)存地址對(duì)應(yīng)的緩存段,如果沒(méi)有就把整個(gè)緩存段從內(nèi)存(或更高一級(jí)的緩存)中加載進(jìn)來(lái)。注意,這里說(shuō)的是一次加載整個(gè)緩存段,這就是上面提過(guò)的局部性原理

上面說(shuō)了,LOCK#會(huì)鎖總線,實(shí)際上這不現(xiàn)實(shí),因?yàn)殒i總線效率太低了。因此最好能做到:使用多組緩存,但是它們的行為看起來(lái)只有一組緩存那樣。緩存一致性協(xié)議就是為了做到這一點(diǎn)而設(shè)計(jì)的,就像名稱所暗示的那樣,這類協(xié)議就是要使多組緩存的內(nèi)容保持一致。

緩存一致性協(xié)議有多種,但是日常處理的大多數(shù)計(jì)算機(jī)設(shè)備都屬于"嗅探(snooping)"協(xié)議,它的基本思想是:

所有內(nèi)存的傳輸都發(fā)生在一條共享的總線上,而所有的處理器都能看到這條總線:緩存本身是獨(dú)立的,但是內(nèi)存是共享資源,所有的內(nèi)存訪問(wèn)都要經(jīng)過(guò)仲裁(同一個(gè)指令周期中,只有一個(gè)CPU緩存可以讀寫(xiě)內(nèi)存)。

CPU緩存不僅僅在做內(nèi)存?zhèn)鬏數(shù)臅r(shí)候才與總線打交道,而是不停在嗅探總線上發(fā)生的數(shù)據(jù)交換,跟蹤其他緩存在做什么。所以當(dāng)一個(gè)緩存代表它所屬的處理器去讀寫(xiě)內(nèi)存時(shí),其它處理器都會(huì)得到通知,它們以此來(lái)使自己的緩存保持同步。只要某個(gè)處理器一寫(xiě)內(nèi)存,其它處理器馬上知道這塊內(nèi)存在它們的緩存段中已失效。

MESI協(xié)議是當(dāng)前最主流的緩存一致性協(xié)議,在MESI協(xié)議中,每個(gè)緩存行有4個(gè)狀態(tài),可用2個(gè)bit表示,它們分別是:

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

這里的I、S和M狀態(tài)已經(jīng)有了對(duì)應(yīng)的概念:失效/未載入、干凈以及臟的緩存段。所以這里新的知識(shí)點(diǎn)只有E狀態(tài),代表獨(dú)占式訪問(wèn),這個(gè)狀態(tài)解決了"在我們開(kāi)始修改某塊內(nèi)存之前,我們需要告訴其它處理器"這一問(wèn)題:只有當(dāng)緩存行處于E或者M(jìn)狀態(tài)時(shí),處理器才能去寫(xiě)它,也就是說(shuō)只有在這兩種狀態(tài)下,處理器是獨(dú)占這個(gè)緩存行的。當(dāng)處理器想寫(xiě)某個(gè)緩存行時(shí),如果它沒(méi)有獨(dú)占權(quán),它必須先發(fā)送一條"我要獨(dú)占權(quán)"的請(qǐng)求給總線,這會(huì)通知其它處理器把它們擁有的同一緩存段的拷貝失效(如果有)。只有在獲得獨(dú)占權(quán)后,處理器才能開(kāi)始修改數(shù)據(jù)----并且此時(shí)這個(gè)處理器知道,這個(gè)緩存行只有一份拷貝,在我自己的緩存里,所以不會(huì)有任何沖突。

反之,如果有其它處理器想讀取這個(gè)緩存行(馬上能知道,因?yàn)橐恢痹谛崽娇偩€),獨(dú)占或已修改的緩存行必須先回到"共享"狀態(tài)。如果是已修改的緩存行,那么還要先把內(nèi)容回寫(xiě)到內(nèi)存中。

由lock指令回看volatile變量讀寫(xiě)

相信有了上面對(duì)于lock的解釋,volatile關(guān)鍵字的實(shí)現(xiàn)原理應(yīng)該是一目了然了。首先看一張圖:

Java中volatile關(guān)鍵字實(shí)現(xiàn)原理

工作內(nèi)存Work Memory其實(shí)就是對(duì)CPU寄存器和高速緩存的抽象,或者說(shuō)每個(gè)線程的工作內(nèi)存也可以簡(jiǎn)單理解為CPU寄存器和高速緩存。

那么當(dāng)寫(xiě)兩條線程Thread-A與Threab-B同時(shí)操作主存中的一個(gè)volatile變量i時(shí),Thread-A寫(xiě)了變量i,那么:

  • Thread-A發(fā)出LOCK#指令
  • 發(fā)出的LOCK#指令鎖總線(或鎖緩存行),同時(shí)讓Thread-B高速緩存中的緩存行內(nèi)容失效
  • Thread-A向主存回寫(xiě)最新修改的i
  • Thread-B讀取變量i,那么:
  • Thread-B發(fā)現(xiàn)對(duì)應(yīng)地址的緩存行被鎖了,等待鎖的釋放,緩存一致性協(xié)議會(huì)保證它讀取到最新的值

由此可以看出,volatile關(guān)鍵字的讀和普通變量的讀取相比基本沒(méi)差別,差別主要還是在變量的寫(xiě)操作上。

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI