3.1 Java記憶體模型的基礎
3.1.1 併發程式設計模型的兩個關鍵問題
併發程式設計中，有兩大關鍵問題：執行緒之間如何通訊和執行緒之間如何同步。通訊是指執行緒之間以何種機制來交換資訊。在指令式程式設計中，執行緒之間的通訊機制有兩種：共享記憶體和訊息傳遞。
在共享記憶體的併發模型裡，執行緒之間共享程式的公共狀態，通過寫-讀記憶體中的公共狀態
進行隱式通訊。
在訊息傳遞的併發模型裡，執行緒之間沒有公共狀態，執行緒之間必須通過傳送訊息來顯式進行通訊。
同步是指程式中用於控制不同執行緒間操作發生相對順序的機制。在共享記憶體併發模型裡，同步是顯式進行的。程式設計師必須顯式指定某個方法或某段程式碼需要線上程之間互斥執行。（例如synchronized修飾方法或程式碼塊）

在訊息傳遞的併發模型裡，由於訊息的傳送必須在訊息的接收之前，因此同步是隱式進行的。
Java的併發採用的是共享記憶體模型，Java執行緒之間的通訊總是隱式進行，整個通訊過程對程式設計師完全透明。如果編寫多執行緒程式的Java程式設計師不理解隱式進行的執行緒之間通訊的工作機制，很可能會遇到各種奇怪的記憶體可見性問題。

3.1.2java記憶體模型的抽象結構
在Java中，所有例項域、靜態域和陣列元素都儲存在堆記憶體中，堆記憶體線上程之間共享（本章用“共享變數”這個術語代指例項域，靜態域和陣列元素）。區域性變數（Local Variables），方法定義引數（Java語言規範稱之為Formal Method Parameters）和異常處理器引數（Exception Handler Parameters）不會線上程之間共享，它們不會有記憶體可見性問題，也不受記憶體模型的影響。

Java執行緒之間的通訊由Java記憶體模型（本文簡稱為JMM）控制，JMM決定一個執行緒對共享變數的寫入何時對另一個執行緒可見。從抽象的角度來看，JMM定義了執行緒和主記憶體之間的抽象關係：執行緒之間的共享變數儲存在主記憶體（Main Memory）中，每個執行緒都有一個私有的本地記憶體（Local Memory），本地記憶體中儲存了該執行緒以讀/寫共享變數的副本。本地記憶體是JMM的一個抽象概念，並不真實存在。它涵蓋了快取、寫緩衝區、暫存器以及其他的硬體和編譯器優化。Java記憶體模型的抽象示意如圖3-1所示。

從圖3-1來看，如果執行緒A與執行緒B之間要通訊的話，必須要經歷下面2個步驟。
1）執行緒A把本地記憶體A中更新過的共享變數重新整理到主記憶體中去。
2）執行緒B到主記憶體中去讀取執行緒A之前已更新過的共享變數。
下面通過示意圖（見圖3-2）來說明這兩個步驟。

如圖3-2所示，本地記憶體A和本地記憶體B由主記憶體中共享變數x的副本。假設初始時，這3個記憶體中的x值都為0。執行緒A在執行時，把更新後的x值（假設值為1）臨時存放在自己的本地記憶體A中。當執行緒A和執行緒B需要通訊時，執行緒A首先會把自己本地記憶體中修改後的x值重新整理到主記憶體中，此時主記憶體中的x值變為了1。隨後，執行緒B到主記憶體中去讀取執行緒A更新後的x值，此時執行緒B的本地記憶體的x值也變為了1。
從整體來看，這兩個步驟實質上是執行緒A在向執行緒B傳送訊息，而且這個通訊過程必須要經過主記憶體。JMM通過控制主記憶體與每個執行緒的本地記憶體之間的互動，來為Java程式設計師提供記憶體可見性保證。

3.1.3 從原始碼到指令序列的重排序

在執行程式時，為了提高效能，編譯器和處理器常常會對指令做重排序。重排序分3種類
型。
1）編譯器優化的重排序。編譯器在不改變單執行緒程式語義的前提下，可以重新安排語句
的執行順序。
2）指令級並行的重排序。現代處理器採用了指令級並行技術（Instruction-Level
Parallelism，ILP）來將多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
3）記憶體系統的重排序。由於處理器使用快取和讀/寫緩衝區，這使得載入和儲存操作看上去可能是在亂序執行。
從Java原始碼到最終實際執行的指令序列，會分別經歷下面3種重排序，如圖3-3所示。

上述的1屬於編譯器重排序，2和3屬於處理器重排序。這些重排序可能會導致多執行緒程式
出現記憶體可見性問題。對於編譯器，JMM的編譯器重排序規則會禁止特定型別的編譯器重排序（不是所有的編譯器重排序都要禁止）。對於處理器重排序，JMM的處理器重排序規則會要求Java編譯器在生成指令序列時，插入特定型別的記憶體屏障（Memory Barriers，Intel稱之為Memory Fence）指令，通過記憶體屏障指令來禁止特定型別的處理器重排序。

JMM屬於語言級的記憶體模型，它確保在不同的編譯器和不同的處理器平臺之上，通過禁止特定型別的編譯器重排序和處理器重排序，為程式設計師提供一致的記憶體可見性保證。
3.1.4 併發程式設計模型的分類
現代的處理器使用寫緩衝區臨時儲存向記憶體寫入的資料。寫緩衝區可以保證指令流水線持續執行，它可以避免由於處理器停頓下來等待向記憶體寫入資料而產生的延遲。同時，通過以批處理的方式重新整理寫緩衝區，以及合併寫緩衝區中對同一記憶體地址的多次寫，減少對記憶體匯流排的佔用。雖然寫緩衝區有這麼多好處，但每個處理器上的寫緩衝區，僅僅對它所在的處理器可見。這個特性會對記憶體操作的執行順序產生重要的影響：處理器對記憶體的讀/寫操作的執行順序，不一定與記憶體實際發生的讀/寫操作順序一致！為了具體說明，請看下面的表3-1。

假設處理器A和處理器B按程式的順序並行執行記憶體訪問，最終可能得到x=y=0的結果。具體的原因如圖3-4所示。

這裡處理器A和處理器B可以同時把共享變數寫入自己的寫緩衝區（A1，B1），然後從記憶體中讀取另一個共享變數（A2，B2），最後才把自己寫快取區中儲存的髒資料重新整理到記憶體中（A3，B3）。當以這種時序執行時，程式就可以得到x=y=0的結果。

從記憶體操作實際發生的順序來看，直到處理器A執行A3來重新整理自己的寫快取區，寫操作A1才算真正執行了。雖然處理器A執行記憶體操作的順序為：A1→A2，但記憶體操作實際發生的順序卻A2→A1。此時，處理器A的記憶體操作順序被重排序了（處理器B的情況和處理器A一樣，這裡就不贅述了）。
這裡的關鍵是，由於寫緩衝區僅對自己的處理器可見，它會導致處理器執行記憶體操作的順序可能會與記憶體實際的操作執行順序不一致。由於現代的處理器都會使用寫緩衝區，因此現代的處理器都會允許對寫-讀操作進行重排序。

表3-2是常見處理器允許的重排序型別的列表。

注意，表3-2單元格中的“N”表示處理器不允許兩個操作重排序，“Y”表示允許重排序。
從表3-2我們可以看出：常見的處理器都允許Store-Load重排序；常見的處理器都不允許對
存在資料依賴的操作做重排序。sparc-TSO和X86擁有相對較強的處理器記憶體模型，它們僅允
許對寫-讀操作做重排序（因為它們都使用了寫緩衝區）。

3.1.5 happens-before簡介
從JDK 5開始，Java使用新的JSR-133記憶體模型（除非特別說明，本文針對的都是JSR-133內
存模型）。JSR-133使用happens-before的概念來闡述操作之間的記憶體可見性。在JMM中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須要存在happens-before關係。這裡提到的兩個操作既可以是在一個執行緒之內，也可以是在不同執行緒之間。

與程式設計師密切相關的happens-before規則如下。
·程式順序規則：一個執行緒中的每個操作，happens-before於該執行緒中的任意後續操作。
·監視器鎖規則：對一個鎖的解鎖，happens-before於隨後對這個鎖的加鎖。
·volatile變數規則：對一個volatile域的寫，happens-before於任意後續對這個volatile域的
讀。
·傳遞性：如果A happens-before B，且B happens-before C，那麼A happens-before C。

注意:兩個操作之間具有happens-before關係，並不意味著前一個操作必須要在後一個操作之前執行！happens-before僅僅要求前一個操作（執行的結果）對後一個操作可見，且前一個操作按順序排在第二個操作之前（the first is visible to and ordered before the second）。
happens-before的定義很微妙，後文會具體說明happens-before為什麼要這麼定義。
happens-before與JMM的關係如圖3-5所示。

如圖3-5所示，一個happens-before規則對應於一個或多個編譯器和處理器重排序規則。對
於Java程式設計師來說，happens-before規則簡單易懂，它避免Java程式設計師為了理解JMM提供的記憶體
可見性保證而去學習複雜的重排序規則以及這些規則的具體實現方法。