2. 程式人生 > >Java中volatile關鍵字實現原理

Java中volatile關鍵字實現原理

阿新 • • 發佈：2017-11-03
三級 poll 解讀 內存屏障 就會 主存 發生 調用 獲得

原文地址http://www.cnblogs.com/xrq730/p/7048693.html，轉載請註明出處，謝謝

前言

我們知道volatile關鍵字的作用是保證變量在多線程之間的可見性，它是java.util.concurrent包的核心，沒有volatile就沒有這麽多的並發類給我們使用。

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

CPU緩存

CPU緩存的出現主要是為了解決CPU運算速度與內存讀寫速度不匹配的矛盾

，因為CPU運算速度要比內存讀寫速度快得多，舉個例子：

  • 一次主內存的訪問通常在幾十到幾百個時鐘周期
  • 一次L1高速緩存的讀寫只需要1~2個時鐘周期
  • 一次L2高速緩存的讀寫也只需要數十個時鐘周期

這種訪問速度的顯著差異，導致CPU可能會花費很長時間等待數據到來或把數據寫入內存。

基於此，現在CPU大多數情況下讀寫都不會直接訪問內存（CPU都沒有連接到內存的管腳），取而代之的是CPU緩存，CPU緩存是位於CPU與內存之間的臨時存儲器，它的容量比內存小得多但是交換速度卻比內存快得多。而緩存中的數據是內存中的一小部分數據，但這一小部分是短時間內CPU即將訪問的，當CPU調用大量數據時，就可先從緩存中讀取，從而加快讀取速度。

按照讀取順序與CPU結合的緊密程度，CPU緩存可分為：

  • 一級緩存：簡稱L1 Cache，位於CPU內核的旁邊，是與CPU結合最為緊密的CPU緩存
  • 二級緩存：簡稱L2 Cache，分內部和外部兩種芯片，內部芯片二級緩存運行速度與主頻相同，外部芯片二級緩存運行速度則只有主頻的一半
  • 三級緩存：簡稱L3 Cache，部分高端CPU才有

每一級緩存中所存儲的數據全部都是下一級緩存中的一部分，這三種緩存的技術難度和制造成本是相對遞減的，所以其容量也相對遞增。

當CPU要讀取一個數據時，首先從一級緩存中查找，如果沒有再從二級緩存中查找，如果還是沒有再從三級緩存中或內存中查找。一般來說每級緩存的命中率大概都有80%左右，也就是說全部數據量的80%都可以在一級緩存中找到，只剩下20%的總數據量才需要從二級緩存、三級緩存或內存中讀取。

使用CPU緩存帶來的問題

用一張圖表示一下CPU-->CPU緩存-->主內存數據讀取之間的關系：

技術分享

當系統運行時，CPU執行計算的過程如下：

  1. 程序以及數據被加載到主內存
  2. 指令和數據被加載到CPU緩存
  3. CPU執行指令，把結果寫到高速緩存
  4. 高速緩存中的數據寫回主內存

如果服務器是單核CPU，那麽這些步驟不會有任何的問題，但是如果服務器是多核CPU，那麽問題來了，以Intel Core i7處理器的高速緩存概念模型為例（圖片摘自《深入理解計算機系統》）：

技術分享

試想下面一種情況：

  1. 核0讀取了一個字節，根據局部性原理，它相鄰的字節同樣被被讀入核0的緩存
  2. 核3做了上面同樣的工作，這樣核0與核3的緩存擁有同樣的數據
  3. 核0修改了那個字節，被修改後，那個字節被寫回核0的緩存，但是該信息並沒有寫回主存
  4. 核3訪問該字節，由於核0並未將數據寫回主存，數據不同步

為了解決這個問題，CPU制造商制定了一個規則：當一個CPU修改緩存中的字節時，服務器中其他CPU會被通知，它們的緩存將視為無效。於是，在上面的情況下，核3發現自己的緩存中數據已無效，核0將立即把自己的數據寫回主存，然後核3重新讀取該數據。

反匯編Java字節碼，查看匯編層面對volatile關鍵字做了什麽

有了上面的理論基礎，我們可以研究volatile關鍵字到底是如何實現的。首先寫一段簡單的代碼：

技術分享 
 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7048693.html
 3  */
 4 public class LazySingleton {
 5 
 6     private static volatile LazySingleton instance = null;
 7     
 8     public static LazySingleton getInstance() {
 9         if (instance == null) {
10             instance = new LazySingleton();
11         }
12         
13         return instance;
14     }
15     
16     public static void main(String[] args) {
17         LazySingleton.getInstance();
18     }
19     
20 }
技術分享

首先反編譯一下這段代碼的.class文件，看一下生成的字節碼：

技術分享

沒有任何特別的。要知道，字節碼指令，比如上圖的getstatic、ifnonnull、new等，最終對應到操作系統的層面，都是轉換為一條一條指令去執行，我們使用的PC機、應用服務器的CPU架構通常都是IA-32架構的，這種架構采用的指令集是CISC（復雜指令集），而匯編語言則是這種指令集的助記符。

因此，既然在字節碼層面我們看不出什麽端倪，那下面就看看將代碼轉換為匯編指令能看出什麽端倪。Windows上要看到以上代碼對應的匯編碼不難（吐槽一句，說說不難，為了這個問題我找遍了各種資料，差點就準備安裝虛擬機，在Linux系統上搞了），訪問hsdis工具路徑可直接下載hsdis工具，下載完畢之後解壓，將hsdis-amd64.dll與hsdis-amd64.lib兩個文件放在%JAVA_HOME%\jre\bin\server路徑下即可，如下圖：

技術分享

然後跑main函數，跑main函數之前，加入如下虛擬機參數：

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

運行main函數即可，代碼生成的匯編指令為：

技術分享 
 1 Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output
 2 CompilerOracle: compileonly *LazySingleton.getInstance
 3 Loaded disassembler from D:\JDK\jre\bin\server\hsdis-amd64.dll
 4 Decoding compiled method 0x0000000002931150:
 5 Code:
 6 Argument 0 is unknown.RIP: 0x29312a0 Code size: 0x00000108
 7 [Disassembling for mach=‘amd64‘]
 8 [Entry Point]
 9 [Verified Entry Point]
10 [Constants]
11   # {method} ‘getInstance‘ ‘()Lorg/xrq/test/design/singleton/LazySingleton;‘ in ‘org/xrq/test/design/singleton/LazySingleton‘
12   #           [sp+0x20]  (sp of caller)
13   0x00000000029312a0: mov     dword ptr [rsp+0ffffffffffffa000h],eax
14   0x00000000029312a7: push    rbp
15   0x00000000029312a8: sub     rsp,10h           ;*synchronization entry
16                                                 ; - org.xrq.test.design.singleton.LazySingleton::getInstance@-1 (line 13)
17   0x00000000029312ac: mov     r10,7ada9e428h    ;   {oop(a ‘java/lang/Class‘ = ‘org/xrq/test/design/singleton/LazySingleton‘)}
18   0x00000000029312b6: mov     r11d,dword ptr [r10+58h]
19                                                 ;*getstatic instance
20                                                 ; - org.xrq.test.design.singleton.LazySingleton::getInstance@0 (line 13)
21   0x00000000029312ba: test    r11d,r11d
22   0x00000000029312bd: je      29312e0h
23   0x00000000029312bf: mov     r10,7ada9e428h    ;   {oop(a ‘java/lang/Class‘ = ‘org/xrq/test/design/singleton/LazySingleton‘)}
24   0x00000000029312c9: mov     r11d,dword ptr [r10+58h]
25   0x00000000029312cd: mov     rax,r11
26   0x00000000029312d0: shl     rax,3h            ;*getstatic instance
27                                                 ; - org.xrq.test.design.singleton.LazySingleton::getInstance@16 (line 17)
28   0x00000000029312d4: add     rsp,10h
29   0x00000000029312d8: pop     rbp
30   0x00000000029312d9: test    dword ptr [330000h],eax  ;   {poll_return}
31   0x00000000029312df: ret
32   0x00000000029312e0: mov     rax,qword ptr [r15+60h]
33   0x00000000029312e4: mov     r10,rax
34   0x00000000029312e7: add     r10,10h
35   0x00000000029312eb: cmp     r10,qword ptr [r15+70h]
36   0x00000000029312ef: jnb     293135bh
37   0x00000000029312f1: mov     qword ptr [r15+60h],r10
38   0x00000000029312f5: prefetchnta byte ptr [r10+0c0h]
39   0x00000000029312fd: mov     r11d,0e07d00b2h   ;   {oop(‘org/xrq/test/design/singleton/LazySingleton‘)}
40   0x0000000002931303: mov     r10,qword ptr [r12+r11*8+0b0h]
41   0x000000000293130b: mov     qword ptr [rax],r10
42   0x000000000293130e: mov     dword ptr [rax+8h],0e07d00b2h
43                                                 ;   {oop(‘org/xrq/test/design/singleton/LazySingleton‘)}
44   0x0000000002931315: mov     dword ptr [rax+0ch],r12d
45   0x0000000002931319: mov     rbp,rax           ;*new  ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
46   0x000000000293131c: mov     rdx,rbp
47   0x000000000293131f: call    2907c60h          ; OopMap{rbp=Oop off=132}
48                                                 ;*invokespecial <init>
49                                                 ; - org.xrq.test.design.singleton.LazySingleton::getInstance@10 (line 14)
50                                                 ;   {optimized virtual_call}
51   0x0000000002931324: mov     r10,rbp
52   0x0000000002931327: shr     r10,3h
53   0x000000000293132b: mov     r11,7ada9e428h    ;   {oop(a ‘java/lang/Class‘ = ‘org/xrq/test/design/singleton/LazySingleton‘)}
54   0x0000000002931335: mov     dword ptr [r11+58h],r10d
55   0x0000000002931339: mov     r10,7ada9e428h    ;   {oop(a ‘java/lang/Class‘ = ‘org/xrq/test/design/singleton/LazySingleton‘)}
56   0x0000000002931343: shr     r10,9h
57   0x0000000002931347: mov     r11d,20b2000h
58   0x000000000293134d: mov     byte ptr [r11+r10],r12l
59   0x0000000002931351: lock add dword ptr [rsp],0h  ;*putstatic instance
60                                                 ; - org.xrq.test.design.singleton.LazySingleton::getInstance@13 (line 14)
61   0x0000000002931356: jmp     29312bfh
62   0x000000000293135b: mov     rdx,703e80590h    ;   {oop(‘org/xrq/test/design/singleton/LazySingleton‘)}
63   0x0000000002931365: nop
64   0x0000000002931367: call    292fbe0h          ; OopMap{off=204}
65                                                 ;*new  ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
66                                                 ;   {runtime_call}
67   0x000000000293136c: jmp     2931319h
68   0x000000000293136e: mov     rdx,rax
69   0x0000000002931371: jmp     2931376h
70   0x0000000002931373: mov     rdx,rax           ;*new  ; - org.xrq.test.design.singleton.LazySingleton::getInstance@6 (line 14)
71   0x0000000002931376: add     rsp,10h
72   0x000000000293137a: pop     rbp
73   0x000000000293137b: jmp     2932b20h          ;   {runtime_call}
74 [Stub Code]
75   0x0000000002931380: mov     rbx,0h            ;   {no_reloc}
76   0x000000000293138a: jmp     293138ah          ;   {runtime_call}
77 [Exception Handler]
78   0x000000000293138f: jmp     292fca0h          ;   {runtime_call}
79 [Deopt Handler Code]
80   0x0000000002931394: call    2931399h
81   0x0000000002931399: sub     qword ptr [rsp],5h
82   0x000000000293139e: jmp     2909000h          ;   {runtime_call}
83   0x00000000029313a3: hlt
84   0x00000000029313a4: hlt
85   0x00000000029313a5: hlt
86   0x00000000029313a6: hlt
87   0x00000000029313a7: hlt
技術分享

這麽長長的匯編代碼，可能大家不知道CPU在哪裏做了手腳，沒事不難，定位到59、60兩行：

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

之所以定位到這兩行是因為這裏結尾寫明了line 14，line 14即volatile變量instance賦值的地方。後面的add dword ptr [rsp],0h都是正常的匯編語句，意思是將雙字節的棧指針寄存器+0，這裏的關鍵就是add前面的lock指令，後面詳細分析一下lock指令的作用和為什麽加上lock指令後就能保證volatile關鍵字的內存可見性。

lock指令做了什麽

之前有說過IA-32架構，關於CPU架構的問題大家有興趣的可以自己查詢一下，這裏查詢一下IA-32手冊關於lock指令的描述，沒有IA-32手冊的可以去這個地址下載IA-32手冊下載地址，是個中文版本的手冊。

我摘抄一下IA-32手冊中關於lock指令作用的一些描述（因為lock指令的作用在手冊中散落在各處，並不是在某一章或者某一節專門講）：

技術分享 
在修改內存操作時，使用LOCK前綴去調用加鎖的讀-修改-寫操作，這種機制用於多處理器系統中處理器之間進行可靠的通訊，具體描述如下：
（1）在Pentium和早期的IA-32處理器中，LOCK前綴會使處理器執行當前指令時產生一個LOCK#信號，這種總是引起顯式總線鎖定出現
（2）在Pentium4、Inter Xeon和P6系列處理器中，加鎖操作是由高速緩存鎖或總線鎖來處理。如果內存訪問有高速緩存且只影響一個單獨的高速緩存行，那麽操作中就會調用高速緩存鎖，而系統總線和系統內存中的實際區域內不會被鎖定。同時，這條總線上的其它Pentium4、Intel Xeon或者P6系列處理器就回寫所有已修改的數據並使它們的高速緩存失效，以保證系統內存的一致性。如果內存訪問沒有高速緩存且/或它跨越了高速緩存行的邊界，那麽這個處理器就會產生LOCK#信號，並在鎖定操作期間不會響應總線控制請求
技術分享 技術分享 
32位IA-32處理器支持對系統內存中的某個區域進行加鎖的原子操作。這些操作常用來管理共享的數據結構（如信號量、段描述符、系統段或頁表），兩個或多個處理器可能同時會修改這些數據結構中的同一數據域或標誌。處理器使用三個相互依賴的機制來實現加鎖的原子操作：
1、保證原子操作
2、總線加鎖，使用LOCK#信號和LOCK指令前綴
3、高速緩存相幹性協議，確保對高速緩存中的數據結構執行原子操作（高速緩存鎖）。這種機制存在於Pentium4、Intel Xeon和P6系列處理器中
技術分享 
IA-32處理器提供有一個LOCK#信號，會在某些關鍵內存操作期間被自動激活，去鎖定系統總線。當這個輸出信號發出的時候，來自其他處理器或總線代理的控制請求將被阻塞。軟件能夠通過預先在指令前添加LOCK前綴來指定需要LOCK語義的其它場合。
在Intel386、Intel486、Pentium處理器中，明確地對指令加鎖會導致LOCK#信號的產生。由硬件設計人員來保證系統硬件中LOCK#信號的可用性，以控制處理器間的內存訪問。
對於Pentinum4、Intel Xeon以及P6系列處理器，如果被訪問的內存區域是在處理器內部進行高速緩存的，那麽通常不發出LOCK#信號；相反，加鎖只應用於處理器的高速緩存。
技術分享 
為顯式地強制執行LOCK語義，軟件可以在下列指令修改內存區域時使用LOCK前綴。當LOCK前綴被置於其它指令之前或者指令沒有對內存進行寫操作（也就是說目標操作數在寄存器中）時，會產生一個非法操作碼異常（#UD）。
【1】位測試和修改指令（BTS、BTR、BTC）
【2】交換指令（XADD、CMPXCHG、CMPXCHG8B）
【3】自動假設有LOCK前綴的XCHG指令
【4】下列單操作數的算數和邏輯指令：INC、DEC、NOT、NEG
【5】下列雙操作數的算數和邏輯指令：ADD、ADC、SUB、SBB、AND、OR、XOR
一個加鎖的指令會保證對目標操作數所在的內存區域加鎖，但是系統可能會將鎖定區域解釋得稍大一些。
軟件應該使用相同的地址和操作數長度來訪問信號量（用作處理器之間發送信號的共享內存）。例如，如果一個處理器使用一個字來訪問信號量，其它處理器就不應該使用一個字節來訪問這個信號量。
總線鎖的完整性不收內存區域對齊的影響。加鎖語義會一直持續，以滿足更新整個操作數所需的總線周期個數。但是，建議加鎖訪問應該對齊在它們的自然邊界上，以提升系統性能：
【1】任何8位訪問的邊界（加鎖或不加鎖）
【2】鎖定的字訪問的16位邊界
【3】鎖定的雙字訪問的32位邊界
【4】鎖定的四字訪問的64位邊界
對所有其它的內存操作和所有可見的外部事件來說，加鎖的操作都是原子的。所有取指令和頁表操作能夠越過加鎖的指令。加鎖的指令可用於同步一個處理器寫數據而另一個處理器讀數據的操作。
技術分享 技術分享 
IA-32架構提供了幾種機制用來強化或弱化內存排序模型，以處理特殊的編程情形。這些機制包括：
【1】I/O指令、加鎖指令、LOCK前綴以及串行化指令等，強制在處理器上進行較強的排序
【2】SFENCE指令（在Pentium III中引入）和LFENCE指令、MFENCE指令（在Pentium4和Intel Xeon處理器中引入）提供了某些特殊類型內存操作的排序和串行化功能
...（這裏還有兩條就不寫了）
這些機制可以通過下面的方式使用。
總線上的內存映射設備和其它I/O設備通常對向它們緩沖區寫操作的順序很敏感，I/O指令（IN指令和OUT指令）以下面的方式對這種訪問執行強寫操作的排序。在執行了一條I/O指令之前，處理器等待之前的所有指令執行完畢以及所有的緩沖區都被都被寫入了內存。只有取指令和頁表查詢能夠越過I/O指令，後續指令要等到I/O指令執行完畢才開始執行。
技術分享

反復思考IA-32手冊對lock指令作用的這幾段描述，可以得出lock指令的幾個作用：

  1. 鎖總線，其它CPU對內存的讀寫請求都會被阻塞，直到鎖釋放，不過實際後來的處理器都采用鎖緩存替代鎖總線，因為鎖總線的開銷比較大，鎖總線期間其他CPU沒法訪問內存
  2. lock後的寫操作會回寫已修改的數據，同時讓其它CPU相關緩存行失效，從而重新從主存中加載最新的數據
  3. 不是內存屏障卻能完成類似內存屏障的功能，阻止屏障兩遍的指令重排序

（1）中寫了由於效率問題，實際後來的處理器都采用鎖緩存來替代鎖總線，這種場景下多緩存的數據一致是通過緩存一致性協議來保證的，我們來看一下什麽是緩存一致性協議。

緩存一致性協議

講緩存一致性之前，先說一下緩存行的概念：

  • 緩存是分段（line）的，一個段對應一塊存儲空間，我們稱之為緩存行，它是CPU緩存中可分配的最小存儲單元，大小32字節、64字節、128字節不等，這與CPU架構有關，通常來說是64字節。當CPU看到一條讀取內存的指令時，它會把內存地址傳遞給一級數據緩存，一級數據緩存會檢查它是否有這個內存地址對應的緩存段，如果沒有就把整個緩存段從內存（或更高一級的緩存）中加載進來。註意，這裏說的是一次加載整個緩存段，這就是上面提過的局部性原理

上面說了，LOCK#會鎖總線，實際上這不現實，因為鎖總線效率太低了。因此最好能做到：使用多組緩存，但是它們的行為看起來只有一組緩存那樣。緩存一致性協議就是為了做到這一點而設計的，就像名稱所暗示的那樣，這類協議就是要使多組緩存的內容保持一致。

緩存一致性協議有多種，但是日常處理的大多數計算機設備都屬於"嗅探（snooping）"協議，它的基本思想是：

所有內存的傳輸都發生在一條共享的總線上，而所有的處理器都能看到這條總線：緩存本身是獨立的，但是內存是共享資源，所有的內存訪問都要經過仲裁（同一個指令周期中，只有一個CPU緩存可以讀寫內存）。

CPU緩存不僅僅在做內存傳輸的時候才與總線打交道，而是不停在嗅探總線上發生的數據交換，跟蹤其他緩存在做什麽。所以當一個緩存代表它所屬的處理器去讀寫內存時，其它處理器都會得到通知，它們以此來使自己的緩存保持同步。只要某個處理器一寫內存，其它處理器馬上知道這塊內存在它們的緩存段中已失效。

MESI協議是當前最主流的緩存一致性協議，在MESI協議中，每個緩存行有4個狀態，可用2個bit表示，它們分別是：

技術分享

這裏的I、S和M狀態已經有了對應的概念：失效/未載入、幹凈以及臟的緩存段。所以這裏新的知識點只有E狀態，代表獨占式訪問，這個狀態解決了"在我們開始修改某塊內存之前，我們需要告訴其它處理器"這一問題：只有當緩存行處於E或者M狀態時，處理器才能去寫它，也就是說只有在這兩種狀態下，處理器是獨占這個緩存行的。當處理器想寫某個緩存行時，如果它沒有獨占權，它必須先發送一條"我要獨占權"的請求給總線，這會通知其它處理器把它們擁有的同一緩存段的拷貝失效（如果有）。只有在獲得獨占權後，處理器才能開始修改數據----並且此時這個處理器知道，這個緩存行只有一份拷貝，在我自己的緩存裏，所以不會有任何沖突。

反之，如果有其它處理器想讀取這個緩存行（馬上能知道，因為一直在嗅探總線），獨占或已修改的緩存行必須先回到"共享"狀態。如果是已修改的緩存行，那麽還要先把內容回寫到內存中。

由lock指令回看volatile變量讀寫

相信有了上面對於lock的解釋，volatile關鍵字的實現原理應該是一目了然了。首先看一張圖：

技術分享

工作內存Work Memory其實就是對CPU寄存器和高速緩存的抽象，或者說每個線程的工作內存也可以簡單理解為CPU寄存器和高速緩存。

那麽當寫兩條線程Thread-A與Threab-B同時操作主存中的一個volatile變量i時，Thread-A寫了變量i，那麽：

  • Thread-A發出LOCK#指令
  • 發出的LOCK#指令鎖總線（或鎖緩存行），同時讓Thread-B高速緩存中的緩存行內容失效
  • Thread-A向主存回寫最新修改的i

Thread-B讀取變量i，那麽：

  • Thread-B發現對應地址的緩存行被鎖了，等待鎖的釋放，緩存一致性協議會保證它讀取到最新的值

由此可以看出，volatile關鍵字的讀和普通變量的讀取相比基本沒差別，差別主要還是在變量的寫操作上。

後記

之前對於volatile關鍵字的作用我個人還有一些會混淆的誤區，在深入理解volatile關鍵字的作用之後，感覺對volatile的理解深了許多。相信看到文章這裏的你，只要肯想、肯研究，一定會和我一樣有恍然大悟、茅塞頓開的感覺^_^

Java中volatile關鍵字實現原理

相關推薦

就是要你懂Java中volatile關鍵字實現原理

stub string home 技術分享 訪問速度 get 地址傳遞 code 緩沖 原文地址http://www.cnblogs.com/xrq730/p/7048693.html，轉載請註明出處，謝謝 前言 我們知道volatile關鍵字的作用是保證變量在多線程之

Java中volatile關鍵字實現原理

三級 poll 解讀 內存屏障 就會 主存 發生 調用 獲得 原文地址http://www.cnblogs.com/xrq730/p/7048693.html，轉載請註明出處，謝謝 前言 我們知道volatile關鍵字的作用是保證變量在多線程之間的可見性，它是ja

java中volatile關鍵字的含義

能夠 system 內存區域 退出 tro 技術 2.4 虛擬機 們的 在java線程並發處理中，有一個關鍵字volatile的使用目前存在很大的混淆，以為使用這個關鍵字，在進行多線程並發處理的時候就可以萬事大吉。 Java語言是支持多線程的，為了解決線程並發的問題，在語

[轉] java中volatile關鍵字的含義

讀取 add 由於 tar 並不是 ges 內部 post 計數 在java線程並發處理中，有一個關鍵字volatile的使用目前存在很大的混淆，以為使用這個關鍵字，在進行多線程並發處理的時候就可以萬事大吉。 Java語言是支持多線程的，為了解決線程並發的問題，在

Java中HashMap底層實現原理(JDK1.8)源碼分析

blank imp dash logs || 屬性 lte das ces 這幾天學習了HashMap的底層實現,但是發現好幾個版本的，代碼不一，而且看了Android包的HashMap和JDK中的HashMap的也不是一樣，原來他們沒有指定JDK版本，很多文章都是舊版本J

Java中，Java中volatile關鍵字十分重要

　　在Java中，Java中volatile關鍵字十分重要 　　 　　本文全面 & 詳細解析volatile關鍵字，希望你們會喜歡 　　 　　目錄 　　 　　1. 定義 　　 　　Java 中的1個關鍵字 / 修飾符 　　 　　2. 作用 　　 　　保證 被 volatile修飾的共享變數

Java中volatile關鍵字淺析

1.基本理解 a. 可見性：指多個執行緒之間對共享變數的可見性，一個執行緒修改狀態時別的執行緒是可見的（意思是一個執行緒改變了狀態，別的執行緒能夠立馬及時的看到）。用volatile修飾的變數，當一個執行緒改變了狀態時，其他執行緒會立馬放棄各自快取中的值，直接從主存中獲取最新值重新整理自己的

ReentrantLock在Java中Lock的實現原理拿鎖過程分析

import java.util.concurrent.locks.ReentrantLock; public class App { public static void main(String[] args) throws Exception {

一文帶你理解Java中Lock的實現原理

當多個執行緒需要訪問某個公共資源的時候，我們知道需要通過加鎖來保證資源的訪問不會出問題。java提供了兩種方式來加鎖，一種是關鍵字：synchronized，一種是concurrent包下的lock鎖。synchronized是java底層支援的，而concurrent包

Java中Volatile關鍵字詳解（轉）

一、基本概念 先補充一下概念：Java 記憶體模型中的可見性、原子性和有序性。 可見性： 　　可見性是一種複雜的屬性，因為可見性中的錯誤總是會違揹我們的直覺。通常，我們無法確保執行讀操作的執行緒能適時地看到其他執行緒寫入的值，有時甚至是根本不可能的事情。為了確保多個執行

演算法---hash演算法原理(java中HashMap底層實現原理和原始碼解析)

散列表（Hash table，也叫雜湊表），是依據關鍵碼值(Key value)而直接進行訪問的資料結構。也就是說，它通過把關鍵碼值對映到表中一個位置來訪問記錄，以加快查詢的速度。這個對映函式叫做雜湊函式，存放記錄的陣列叫做散列表。  比如我們要儲存八十八個資料,我們為他申請了100個

Java中HashMap底層實現原理(JDK1.8)原始碼分析

在JDK1.6，JDK1.7中，HashMap採用位桶+連結串列實現，即使用連結串列處理衝突，同一hash值的連結串列都儲存在一個連結串列裡。但是當位於一個桶中的元素較多，即hash值相等的元素較多時，通過key值依次查詢的效率較低。而JDK1.8中，HashMap採用位桶+

（轉載）Java中HashMap底層實現原理(JDK1.8)原始碼分析

近期在看一些java底層的東西，看到一篇分析hashMap不錯的文章，跟大家分享一下。 在JDK1.6，JDK1.7中，HashMap採用位桶+連結串列實現，即使用連結串列處理衝突，同一hash值的連結串列都儲存在一個連結串列裡。但是當位於一個桶中的元素較多，即hash值

Java中HashMap的實現原理

轉載自作者：ZeroRen 一、Java中的hashCode和equals 1、關於hashCode hashCode的存在主要是用於查詢的快捷性，如Hashtable，HashMap等，hashCode是用來在雜湊儲存結構中確定物件的儲存地址的如果兩個物件相同，就

Java中synchronized的實現原理與應用

Java中的每一個物件都可以作為鎖，而在Synchronized實現同步的幾種方式中分別為： 普通同步方法：鎖是當前例項物件 靜態同步方法：鎖是當前類的Class物件 同步方法塊：鎖是Synchronized括號裡配置的物件 任何一個物件都一個Monit

Java 中 synchronized 的實現原理及偏向鎖、輕量級鎖、自旋鎖、公平鎖簡介

    在多執行緒程式設計中，synchronized 一直都是元老級別的存在，很多人都稱之為重量級鎖。本文來簡單介紹synchronized的實現原理，以及為減少獲得鎖和釋放鎖所帶來的效能損耗而引進的偏向鎖與輕量級鎖。     Java中使用synchronized來實現

Java基礎六：Java中Volatile關鍵字詳解

一、基本概念 先補充一下概念：Java 記憶體模型中的可見性、原子性和有序性。 可見性： 可見性是一種複雜的屬性，因為可見性中的錯誤總是會違揹我們的直覺。通常，我們無法確保執行讀操作的執行緒能適時地看到其他執行緒寫入的值，有時甚至是根本不可能的事情。為了確保多個

淺析Java中volatile關鍵字及其作用

在 Java 多執行緒中如何保證執行緒的安全性？那我們可以使用 Synchronized 同步鎖來給需要多個執行緒訪問的程式碼塊加鎖以保證執行緒安全性。使用 synchronized 雖然可以解決多執行緒安全問題，但弊端也很明顯：加鎖後多個執行緒需要判斷鎖，較為消耗資源。所以

Java中Volatile關鍵字詳解

一、基本概念 先補充一下概念：Java 記憶體模型中的可見性、原子性和有序性。 可見性： 　　可見性是一種複雜的屬性，因為可見性中的錯誤總是會違揹我們的直覺。通常，我們無法確保執行讀操作的執行緒能適時地看到其他執行緒寫入的值，有時甚至是根本不可能的事情。為了確保

Java並發包中Lock的實現原理

oid -- 使用 方式 exceptio 就是 protected 而是 一次 1. Lock 的簡介及使用 Lock是java 1.5中引入的線程同步工具，它主要用於多線程下共享資源的控制。本質上Lock僅僅是一個接口（位於源碼包中的java\uti