轉載自?深度好文 | Java 可重入鎖內存可見性分析

一個習以為常的細節

之前在做 ReentrantLock 相關的試驗，試驗本身很簡單，和本文相關的簡化版如下：（提示：以下代碼均可左右滑動）

private static ReentrantLock LOCK = new ReentrantLock(); private static int count = 0; ... // 多線程 run 如下代碼LOCK.lock(); try {count++; } finally {LOCK.unlock(); } ...

就是通過可重入鎖的保護并行對共享變量進行自增。

突然想到一個問題：共享變量 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 隨后的讀取一定是最新的值。然而對于如下代碼有個很容易被忽視的點：

int a = 0; volatile int b = 0; ... a = 1; // line 1 b = 2; // line 2

當線程 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 的底層實現息息相關，查看下面代碼片段對應的匯編代碼：

package main.java.happenbefore; /** * Created by zhoutong on 17/11/18. */ public class MyTest {private static long a;private static int b;private volatile static int c;public static void main(String[] args) {set();setAgain();}public static void set() {a = 1;b = 1;c = 1;}public static void setAgain(){if (c == 1) {a = 2;b = 2;}} }

利用 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 一樣的效果。

參考資料

http://gee.cs.oswego.edu/dl/jmm/cookbook.html

https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html 第 8 章

https://www.ibm.com/developerworks/library/j-jtp03304/index.html

https://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive

http://ifeve.com/java-memory-model-5/

https://en.wikipedia.org/wiki/Memory_barrier

https://en.wikipedia.org/wiki/Javamemorymodel

總結

以上是生活随笔為你收集整理的Java 可重入锁内存可见性分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。