Java 記憶體模型

本書部分摘自《Java 并發編程的藝術》

執行緒通信與同步

在并發編程中，有兩個需要處理的關鍵問題：

• 執行緒之間如何通信
• 執行緒之間如何同步

通信指執行緒之間以何種機制來交換資訊，通信機制有兩種：

• 共享記憶體：通過讀 - 寫記憶體中的公共狀態進行隱式通信
• 訊息傳遞：執行緒之間沒有公共狀態，執行緒之間必須通過發送訊息來顯式進行通信

同步是指程式中用于控制不同執行緒間操作發生的相對順序的機制，在共享記憶體并發模型中，同步是顯式進行的，程式員必須顯式指定某個方法或某段代碼需要在執行緒之間互斥執行，在訊息傳遞的并發模型里，由于訊息的發送必須在訊息的接收之前，因此同步是隱式的

Java 記憶體模型

前面提到執行緒的通信與同步問題，Java 執行緒之間的通信由 Java 記憶體模型（簡稱 JMM）控制，JMM 決定一個執行緒對共享變數的寫入何時對另一個執行緒可見

執行緒之間的共享變數存盤在主記憶體，每個執行緒都一個私有的本地記憶體，本地記憶體中存盤了該執行緒以 讀/寫 共享變數的副本

Java 記憶體模型的抽象示意如圖

如果執行緒 A 和執行緒 B 之間要通信的話，必須經過下面兩個步驟：

1. 執行緒 A 把本地記憶體 A 中更新過的共享變數重繪到主記憶體中
2. 執行緒 B 到主記憶體中去讀取執行緒 A 之前已更新的共享變數

這兩個步驟實際上是執行緒 A 向執行緒 B 發送訊息，而且這個通信程序必須經過主記憶體，JMM 通過控制主記憶體與每個執行緒的本地記憶體之間的互動，來為 Java 程式員提供記憶體可見性保證

重排序

在執行程式時，為了提高性能，編譯器和處理器常常會對指令做重排序，重排序可能會導致執行緒程式出現記憶體可見性問題，下面分別介紹三種型別的重排序以及它們對記憶體可見性的影響：

1. 編譯器優化的重排序

   編譯器在不改變單執行緒程式語意的前提下，可以重新安排陳述句的執行順序

2. 指令級并行的重排序

   現代處理器采用了指令級并行技術來將多條指令重疊執行，如果不存在資料依賴性，處理器可以改變陳述句對應機器指令的執行順序

3. 記憶體系統的重排序

   由于處理器使用快取和 讀/寫 緩沖區，這使得加載和存盤操作看上去可能是在亂序執行

   這里對第三種情況做個詳細解釋，現代處理器使用緩沖區臨時保存向記憶體寫入的資料，此舉可以保證指令流水線持續進行，避免由于處理器停頓下來等待向記憶體寫入資料而產生延遲，但每個處理器上的寫緩沖區，僅僅對它所在的處理器可見，這個特性可能會導致處理器對記憶體的 讀/寫 操作執行順序不一定與記憶體實際發生的 讀/寫 操作順序一致，為了說明情況，請看下表：

   	Processor A	Processor B
   代碼	a = 1; // A1 x = b; // A2	b = 2; // B1 y = a; // B2

   處理器 A 和處理器 B 按程式的順序并行執行記憶體訪問，最終可能得到 x = y = 0 的結果，具體原因如圖

   

   處理器 A 和 處理器 B 同時把共享變數寫入自己的緩沖區（A1、B1），然后從記憶體中讀取另一個共享變數（A2、B2），最后才把快取區中保存的臟資料重繪到記憶體中（A3、B3），這種情況下，程式最后就得到 x = y = 0 的結果

所以 Java 源代碼到最終實際執行的指令序列，會分別經歷以下三種重排序

JMM 保證記憶體可見性

由此可見，JMM 不能任由重排序發生，必須加以控制，否則會引發執行緒不安全問題，為了更好地解釋 JMM 為保證記憶體可見性所采取的措施，首先介紹一些基礎概念

1. 資料依賴性

如果兩個操作訪問同一個變數，且這兩個操作有一個為寫操作，此時這兩個操作之間就存在資料依賴性，只要重排序這兩個操作的執行順序，程式的執行結果就會被改變，編譯器和處理器在重排序時，會遵守資料依賴性，不會改變存在資料依賴關系的兩個操作的執行順序，資料依賴分為下列三種型別：

上面三種情況，只要重排序兩個操作的執行順序，程式的執行結果就會被改變

這里所說的資料依賴性僅針對單個處理器中執行的指令序列和單個執行緒中執行的操作，不同處理器之間和不同執行緒之間的資料依賴性不被編譯器和處理器考慮

2. as-if-serial 語意

as-if-serial 語意的意思是：不管怎么重排序，（單執行緒）程式的執行結果不能被改變，編譯器、runtime 和處理器都必須遵守 as-if-serial 語意，為了遵守 as-if-serial 語意，編譯器和處理器不會對存在資料依賴性關系的操作做重排序

as-if-serial 語意把單執行緒程式保護起來，給程式員創建了一個幻覺：單執行緒程式是按程式的順序來執行的，程式員無需擔心重排序會干擾他們，也無需擔心記憶體可見性問題

3. happens-before 原則

happens-before 是 JMM 最核心的概念，對于 Java 程式員來說，理解 happens-before 是理解 JMM 的關鍵，

從 JDK5 開始，Java 使用新的 JSR-133 記憶體模型，JSR-133 使用 happens-before 的概念來闡述操作之間的記憶體可見性，在 JMM 中，如果一個操作執行的結果需要對另一個操作可見，那么這兩個操作之間必須存在 happens-before 關系，這兩個操作既可以是在一個執行緒之內，也可以是不同執行緒之間

A happens-before B，就是 A 操作先于 B 操作執行，當然這種說法并不準確，兩個操作之間具有 happens-before 關系，僅僅要求前一個操作（執行的結果）對后一個操作可見，且前一個操作按順序排在第二個操作之前

在 JMM 中定義了 happens-before 的原則如下：

• 單執行緒 happens-before 原則：在同一個執行緒中，書寫在前面的操作 happens-before 后面的操作
• 鎖的 happens-before 原則：同一個鎖的 unlock 操作 happens-before 此鎖的 lock 操作
• volatile 的 happens-before 原則：對一個 volatile 變數的寫操作 happens-before 對此變數的任意操作（當然也包括寫操作）
• happens-before 的傳遞性原則：如果 A 操作 happens-before B 操作，B 操作 happens-before C 操作，那么 A 操作 happens-before C 操作
• 執行緒啟動的 happens-before 原則：同一個執行緒的 start 方法 happens-before 此執行緒的其它方法
• 執行緒中斷的 happens-before 原則：對執行緒 interrupt 方法的呼叫 happens-before 被中斷執行緒的檢測到中斷發送的代碼
• 執行緒終結的 happens-before 原則：執行緒中的所有操作都 happens-before 執行緒的終止檢測
• 物件創建的 happens-before 原則：一個物件的初始化完成先于他的 finalize 方法呼叫

有關 happens-before 每一個原則的實作，這里不再具體闡述，只要知道有這么一回事就好了

4. 順序一致性記憶體模型

順序一致性記憶體模型是一個被計算機科學家理想化了的理論參考模型，它為程式員提供了極強的記憶體可見性保證，順序一致性記憶體模型有兩大特征：

• 一個執行緒中的所有操作必須按照程式的順序來執行
• 不管程式是否同步，所有執行緒都只能看到一個單一的操作執行順序，在順序一致性記憶體模型中，每個操作都必須原子執行且立刻對所有執行緒可見

順序一致性記憶體模型為程式員提供的視圖如下：

在概念上，順序一致性模型有一個單一的全域記憶體，這個記憶體通過一個左右擺動的開關可以連接到任意一個線程，同時，每一個執行緒必須按程式的順序來執行記憶體讀/寫操作，從上圖我們可以看出，在任意時間點最多只能有一個執行緒可以連接到記憶體，當多個執行緒并發執行時，圖中的開關裝置能把所有執行緒的所有記憶體 讀/寫 操作串行化

為了更好的理解，下面我們通過兩個示意圖來對順序一致性模型的特性做進一步的說明

假設有兩個執行緒 A 和 B 并發執行，其中 A 執行緒有三個操作，它們在程式中的順序是：A1 -> A2 -> A3，B 執行緒也有三個操作，它們在程式中的順序是：B1 -> B2 -> B3

假設這兩個執行緒使用監視器來正確同步：A 執行緒的三個操作執行后釋放監視器，隨后 B 執行緒獲取同一個監視器，那么程式在順序一致性模型中的執行效果將如下圖所示：

現在再假設這兩個執行緒沒有做同步，下面是這個未同步程式在順序一致性模型中的執行示意圖：

未同步程式在順序一致性模型中雖然整體執行順序是無序的，但所有執行緒都只能看到一個一致的整體執行順序，以上圖為例，執行緒 A 和 B 看到的執行順序都是：B1->A1->A2->B2->A3->B3，之所以能得到這個保證是因為順序一致性記憶體模型中的每個操作必須立即對任意執行緒可見

5. 總結

由于重排序的存在，JMM 不可能實作順序一致性記憶體模型，同時也不可能完全禁止重排序，因為這樣會影響效率，一方面，程式員希望記憶體模型易于理解、易于編程，希望基于一個強記憶體模型來撰寫代碼；另一方面，編譯器和處理器希望記憶體模型對它們的束縛越少越好，這樣它們就可以做盡可能多的優化來提高性能，編譯器和處理器希望實作一個弱記憶體模型，這兩個因素相互矛盾，所以關鍵在于找到一個平衡點

平衡的關鍵在于優化重排序規則，根據前面提到的 happens-before 原則、資料依賴性以及 as-if-serial 原則等規定了編譯器和處理器什么情況允許重排序，什么情況不允許重排序，對于會改變程式執行結果的重排序，JMM 要求編譯器和處理器必須禁止這種重排序，否則不作要求，于是程式員所看到的就是一個保證了記憶體可見性的可靠的記憶體模型

下圖是 JMM 的設計示意圖

從上圖我們也可以發現，JMM 會遵循一個基本原則：只要不改變程式的執行結果（指的是單執行緒程式和正確同步的多執行緒程式），編譯器和處理器怎么優化都可以，例如，如果編譯器經過細致地分析后，認定一個鎖只會被單個執行緒訪問，那么這個鎖可以被消除，再如，如果編譯器經過細致的分析后，認定一個 volatile 變數只會被單個執行緒訪問，那么編譯器可以把這個 volatile 變數當作一個普通變數來對待，這些優化既不會改變程式的執行結果，又能提高程式的執行效率，而從程式員的角度來看，程式員其實并不關心重排序是否真的發生，程式員關心的是只程式執行時的語意不能被改變而已

標籤：Java

上一篇：💻 一文讀懂兩臺計算機之間是如何通信的

下一篇：使用MCSManager搭建Minecraft服務器