java 記憶體模型-09-jmm 彙總

摘要： 處理器記憶體模型 順序一致性記憶體模型是一個理論參考模型，JMM 和處理器記憶體模型在設計時通常會把順序一致性記憶體模型作為參照。 JMM 和處理器記憶體模型在設計時會對順序一致性模型做一些放鬆，因為如果完全按照順序一致性模型來實現處理器和 JMM，那麼很多的處理器和編譯器...

處理器記憶體模型

順序一致性記憶體模型是一個理論參考模型，JMM 和處理器記憶體模型在設計時通常會把順序一致性記憶體模型作為參照。

JMM 和處理器記憶體模型在設計時會對順序一致性模型做一些放鬆，因為如果完全按照順序一致性模型來實現處理器和 JMM，那麼很多的處理器和編譯器優化都要被禁止，這對執行效能將會有很大的影響。

分類

根據對不同型別讀/寫操作組合的執行順序的放鬆，可以把常見處理器的記憶體模型劃分為下面幾種型別：

1. 放鬆程式中寫-讀操作的順序，由此產生了 total store ordering 記憶體模型（簡稱為TSO）。

2. 在前面1的基礎上，繼續放鬆程式中寫-寫操作的順序，由此產生了 partial store order 記憶體模型（簡稱為PSO）。

3. 在前面1和2的基礎上，繼續放鬆程式中讀-寫和讀-讀操作的順序，由此產生了 relaxed memory order 記憶體模型（簡稱為RMO）和 PowerPC 記憶體模型。

注意，這裡處理器對讀/寫操作的放鬆，是以兩個操作之間不存在資料依賴性為前提的（因為處理器要遵守as-if-serial 語義，處理器不會對存在資料依賴性的兩個記憶體操作做重排序）。

• 細節

| 記憶體模型名稱 | 對應的處理器 | Store-Load 重排序 | Store-Store 重排序 | Load-Load 和 Load-Store 重排序 | 可以更早讀取到其它處理器的寫 | 可以更早讀取到當前處理器的寫 |

| TSO | sparc-TSO X64 | Y | | | | Y |

| PSO | sparc-PSO | Y | | Y | | Y |

| RMO | ia64 | Y | Y | Y | | Y |

| PowerPC | PowerPC | Y | Y | Y | Y | Y |

在這個表格中，我們可以看到所有處理器記憶體模型都允許寫-讀重排序，原因在第一章以說明過：它們都使用了寫快取區，寫快取區可能導致寫-讀操作重排序。

同時，我們可以看到這些處理器記憶體模型都允許更早讀到當前處理器的寫，原因同樣是因為寫快取區：由於寫快取區僅對當前處理器可見，這個特性導致當前處理器可以比其他處理器先看到臨時儲存在自己的寫快取區中的寫。

上面表格中的各種處理器記憶體模型，從上到下，模型由強變弱。

越是追求效能的處理器，記憶體模型設計的會越弱。因為這些處理器希望記憶體模型對它們的束縛越少越好，這樣它們就可以做盡可能多的優化來提高效能。

由於常見的處理器記憶體模型比 JMM 要弱，java 編譯器在生成位元組碼時，會在執行指令序列的適當位置插入記憶體屏障來限制處理器的重排序。

同時，由於各種處理器記憶體模型的強弱並不相同，為了在不同的處理器平臺向程式設計師展示一個一致的記憶體模型，JMM 在不同的處理器中需要插入的記憶體屏障的數量和種類也不相同。

JMM 遮蔽了不同處理器記憶體模型的差異，它在不同的處理器平臺之上為java程式設計師呈現了一個一致的記憶體模型。

JMM，處理器記憶體模型與順序一致性記憶體模型之間的關係

JMM是一個語言級的記憶體模型，處理器記憶體模型是硬體級的記憶體模型，順序一致性記憶體模型是一個理論參考模型。

下面是語言記憶體模型，處理器記憶體模型和順序一致性記憶體模型的強弱對比示意圖：

[圖片上傳失敗...(image-60a9e6-1542801451991)]

常見的 4 種處理器記憶體模型比常用的 3 中語言記憶體模型要弱，處理器記憶體模型和語言記憶體模型都比順序一致性記憶體模型要弱。

同處理器記憶體模型一樣，越是追求執行效能的語言，記憶體模型設計的會越弱 。

JMM 的設計

設計

從 JMM 設計者的角度來說，在設計 JMM 時，需要考慮兩個關鍵因素：

• 程式設計師對記憶體模型的使用。

程式設計師希望記憶體模型易於理解，易於程式設計。程式設計師希望基於一個強記憶體模型來編寫程式碼。

• 編譯器和處理器對記憶體模型的實現。

編譯器和處理器希望記憶體模型對它們的束縛越少越好，這樣它們就可以做盡可能多的優化來提高效能。編譯器和處理器希望實現一個弱記憶體模型。

由於這兩個因素互相矛盾，所以 JSR-133 專家組在設計 JMM 時的核心目標就是找到一個好的平衡點：

一方面要為程式設計師提供足夠強的記憶體可見性保證；另一方面，對編譯器和處理器的限制要儘可能的放鬆。

實現

下面讓我們看看 JSR-133 是如何實現這一目標的。

為了具體說明，請看前面提到過的計算圓面積的示例程式碼：

double pi= 3.14;//A
double r= 1.0;//B
double area = pi * r * r; //C

上面計算圓的面積的示例程式碼存在三個happens-before 關係：

1. A happens-before B

2. B happens-before C

3. A happens-before C

由於 A happens-before B，happens-before 的定義會要求：A操作執行的結果要對B可見，且 A 操作的執行順序排在 B 操作之前。

但是從程式語義的角度來說，對 A 和 B 做重排序即不會改變程式的執行結果，也還能提高程式的執行效能（允許這種重排序減少了對編譯器和處理器優化的束縛）。

也就是說，上面這 3 個 happens-before 關係中，雖然 2 和 3 是必需要的，但 1 是不必要的。

禁止重排序分類

因此，JMM 把 happens-before 要求禁止的重排序分為了下面兩類：

1. 會改變程式執行結果的重排序

2. 不會改變程式執行結果的重排序

JMM 對這兩種不同性質的重排序，採取了不同的策略：

1. 對於會改變程式執行結果的重排序，JMM要求編譯器和處理器必須禁止這種重排序。

2. 對於不會改變程式執行結果的重排序，JMM對編譯器和處理器不作要求（JMM 允許這種重排序）。

JMM 的設計示意圖

JMM 向程式設計師提供的happens-before 規則能滿足程式設計師的需求。

1. JMM 的 happens-before 規則不但簡單易懂，而且也向程式設計師提供了足夠強的記憶體可見性保證（有些記憶體可見性保證其實並不一定真實存在，比如上面的 A happens-before B）。

2. JMM 對編譯器和處理器的束縛已經儘可能的少。

從上面的分析我們可以看出，JMM 其實是在遵循一個基本原則：

只要不改變程式的執行結果（指的是單執行緒程式和正確同步的多執行緒程式），編譯器和處理器怎麼優化都行。

比如，如果編譯器經過細緻的分析後，認定一個鎖只會被單個執行緒訪問，那麼這個鎖可以被消除。

再比如，如果編譯器經過細緻的分析後，認定一個volatile 變數僅僅只會被單個執行緒訪問，那麼編譯器可以把這個volatile 變數當作一個普通變數來對待。

這些優化既不會改變程式的執行結果，又能提高程式的執行效率。

JMM 的記憶體可見性保證

Java程式的記憶體可見性保證按程式型別可以分為下列三類：

1、 單執行緒程式。

單執行緒程式不會出現記憶體可見性問題。編譯器，runtime和處理器會共同確保單執行緒程式的執行結果與該程式在順序一致性模型中的執行結果相同。

2、 正確同步的多執行緒程式。

正確同步的多執行緒程式的執行將具有順序一致性（程式的執行結果與該程式在順序一致性記憶體模型中的執行結果相同）。這是JMM關注的重點，JMM通過限制編譯器和處理器的重排序來為程式設計師提供記憶體可見性保證。

3、未同步/未正確同步的多執行緒程式。

JMM 為它們提供了最小安全性保障：執行緒執行時讀取到的值，要麼是之前某個執行緒寫入的值，要麼是預設值（0，null，false）。

只要多執行緒程式是正確同步的，JMM 保證該程式在任意的處理器平臺上的執行結果，與該程式在順序一致性記憶體模型中的執行結果一致。

JSR-133 對舊記憶體模型的修補

JSR-133 對 JDK5 之前的舊記憶體模型的修補主要有兩個：

• 增強volatile 的記憶體語義。

舊記憶體模型允許 volatile 變數與普通變數重排序。JSR-133 嚴格限制 volatile 變數與普通變數的重排序，使 volatile 的寫-讀和鎖的釋放-獲取具有相同的記憶體語義。

• 增強final 的記憶體語義。

在舊記憶體模型中，多次讀取同一個 final 變數的值可能會不相同。

為此，JSR-133 為 final 增加了兩個重排序規則。現在，final 具有了初始化安全性。

More+

ofollow,noindex">FAQ

The JSR-133 Cookbook for Compiler Writers

參考資料

• jmm

http://www.infoq.com/cn/articles/java-memory-model-7