之前在做 ReentrantLock 相關的試驗，試驗本身很簡單，和本文相關的簡化版如下：**（提示：以下代碼均可左右滑動）
就是通過可重入鎖的保護并行對共享變量進行自增。
突然想到一個問題：共享變量 count 沒有加 volatile 修飾，那麼在并發自增的過程當中是如何保持記憶體立即可見的呢？上面的代碼做自增肯定是沒問題的，可見 LOCK 不僅僅保證了獨占性，必定還有一種機制保證了記憶體可見性。
可能很多人和我一樣，對 LOCK 的認知是如此 “理所應當”，以至于從沒有去思考為什麼。就好像每天太陽都會從東方升起而不覺得這有什麼好質疑的。現在既然問到這兒了，那就準備一探究竟。
幾個概念
Java Memory Model (JMM)
即 Java 記憶體模型，直接引用 wiki 定義：
"The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language."
JMM 定義了線程和記憶體之間底層互動的語義和規範，比如多線程對共享變量的寫 / 讀操作是如何互相影響。
Memory ordering
Memory ordering 跟處理器通過總線向記憶體發起讀 (load)寫 (store)的操作順序有關。對于早期的 Intel386 處理器，保證了記憶體底層讀寫順序和代碼保持一緻，我們稱之為 program ordering，即代碼中的記憶體讀寫順序就限定了處理器和記憶體互動的順序，所見即所得。而現代的處理器為了提升指令執行速度，在保證程式語義正确的前提下，允許編譯器對指令進行重排序。也就是說這種指令重排序對于上層代碼是感覺不到的，我們稱之為 processor ordering.
JMM 允許編譯器在指令重排上自由發揮，除非程式員通過 synchronized/volatile/CAS 顯式幹預這種重排機制，建立起同步機制，保證多線程代碼正确運作。
Happens-before
對于 volatile 關鍵字大家都比較熟悉，該關鍵字確定了被修飾變量的記憶體可見性。也就是線程 A 修改了 volatile 變量，那麼線程 B 随後的讀取一定是最新的值。然而對于如下代碼有個很容易被忽視的點：
當線程 A 執行完 line 2 之後，變量 a 的更新值也一同被更新到記憶體當中，JMM 能保證随後線程 B 讀取到 b 後，一定能夠看到 a = 1。之是以有這種機制是因為 JMM 定義了 happens-before 原則，直接貼資料：
Each action in a thread happens-before every action in that thread that comes later in the program order
An unlock on a monitor happens-before every subsequent lock on that same monitor
A write to a volatile field happens-before every subsequent read of that same volatile
A call to Thread.start() on a thread happens-before any actions in the started thread
All actions in a thread happen-before any other thread successfully returns from a Thread.join()on that thread
其中第 3 條就定義了 volatile 相關的 happens-before 原則，類比下面的同步機制，一圖勝千言：
也就是說 volatile 寫操作會把之前的共享變量更新一并釋出出去，而不隻是 volatile 變量本身。Happens-before 原則會保證 volatile 寫之後，針對同一個 volatile 變量讀，後面的所有共享變量都是可見的。
初步釋疑
Happens-before 正是解釋文章開頭問題的關鍵，以公平鎖為例，我們看看 ReentrantLock 擷取鎖 & 釋放鎖的關鍵代碼：
private volatile int state; // 關鍵 volatile 變量protected final int getState() { return state;}// 擷取鎖protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); // 重要！！！讀 volatile 變量 ... // 競争擷取鎖邏輯，省略 }// 釋放鎖protected final boolean tryRelease(int releases) { boolean free = false; ... // 根據狀态判斷是否成功釋放，省略 setState(c); // 重要！！！寫 volatile 變量 return free;} 簡單來說就是對于每一個進入到鎖的臨界區域的線程，都會做三件事情：
擷取鎖，讀取 volatile 變量；
執行臨界區代碼，針對本文是對 count 做自增；
寫 volatile 變量 (即釋出所有寫操作)，釋放鎖。
結合上面 happens-before 概念，那麼 count 變量自然就對其它線程做到可見了。
事情還沒有結束
我們隻是利用 volatile 的 happens-before 原則對問題進行了初步的解釋，happens-before 本身隻是一個 JMM 的限制，然而在底層又是怎麼實作的呢？這裡又有一個重要的概念：記憶體屏障（Memory barriers）。
我們可以把記憶體屏障了解為 JMM 賴以建立的底層機制，wiki 定義：
"A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memoryoperations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier."
簡而言之就是記憶體屏障限制死了屏障前後的記憶體操作順序，抽象出來有四種記憶體屏障（因為記憶體 load/store 最多也就四種組合嘛），具體實作視不同的處理器而不同，我們這裡看最常見的 x86 架構的處理器：
volatile 的 happens-before 原則其實就是依賴的 StoreLoad 記憶體屏障，重點關注 LOCK 指令實作，這和 volatile 的底層實作息息相關，檢視下面代碼片段對應的彙編代碼：
利用 hsdis 檢視對應彙編片段（隻包含關鍵部分）：
可以看到在 set() 方法對 a,b,c 指派後，多出了一行 "lock addl $0x0,(%rsp)"，這行代碼隻是對 stack pointer 加 0，無含義。但通過上文我們得知，x86 架構處理器的 LOCK prefix 指令相當于 StoreLoad 記憶體屏障。LOCK prefix 的指令會觸發處理器做特殊的操作，檢視 Intel 64 and IA-32 開發手冊的相關資料：
"Synchronization mechanisms in multiple-processor systems may depend upon a strong memory-ordering model. Here, a program can use a locking instruction such as the XCHG instruction or the LOCK prefix to ensure that a read-modify-write operation on memory is carried out atomically. Locking operations typically operate like I/O operations in that they wait for all previous instructions to complete and for all buffered writes to drain to memory."
LOCK prefix 會觸發 CPU 緩存回寫到記憶體，而後通過 CPU 緩存一緻性機制（這又是個很大的話題），使得其它處理器核心能夠看到最新的共享變量，實作了共享變量對于所有 CPU 的可見性。
總結
針對本文開頭提出的記憶體可見性問題，有着一系列的技術依賴關系才得以實作：count++ 可見性 → volatile 的 happens-before 原則 → volatile 底層 LOCK prefix 實作 → CPU 緩存一緻性機制。
補充一下，針對 ReentrantLock 非公平鎖的實作，相比公平鎖隻是在争奪鎖的開始多了一步 CAS 操作，而 CAS 在 x86 多處理器架構中同樣對應着 LOCK prefix 指令，是以在記憶體屏障上有着和 volatile 一樣的效果。