前提
《深入了解 Java 記憶體模型》程曉明著，該書在以前看過一遍，現在學的東西越多，感覺那塊越重要，于是又再細看一遍，于是便有了下面的讀書筆記總結。全書頁數雖不多，内容講得挺深的。細看的話，也是挺花時間的，看完收獲絕對挺大的。也建議 Java 開發者都去看看。裡面主要有 Java 記憶體模型的基礎、重排序、順序一緻性、Volatile 關鍵字、鎖、final。本文參考書中内容。
基礎
并發程式設計的模型分類
在并發程式設計需要處理的兩個關鍵問題是： 線程之間如何通信 和 線程之間如何同步 。
通信
通信是指線程之間以何種機制來交換資訊。在指令式程式設計中，線程之間的通信機制有兩種： 共享記憶體 和 消息傳遞 。
在 共享記憶體 的并發模型裡，線程之間共享程式的公共狀态，線程之間通過寫-讀記憶體中的 公共狀态 來 隐式 進行通信。
在 消息傳遞 的并發模型裡，線程之間沒有公共狀态，線程之間必須通過明确的 發送消息 來 顯式 進行通信。
同步
同步是指程式用于控制不同線程之間操作發生相對順序的機制。
在 共享記憶體 的并發模型裡，同步是 顯式 進行的。程式員必須顯式指定某個方法或某段代碼需要線上程之間 互斥執行 。
在 消息傳遞 的并發模型裡，由于消息的發送必須在消息的接收之前，是以同步是 隐式 進行的。
Java 的并發采用的是共享記憶體模型，Java 線程之間的通信總是隐式進行，整個通信過程對程式員完全透明。
Java 記憶體模型的抽象
在 Java 中，所有執行個體域、靜态域 和 數組元素存儲在堆記憶體中，堆記憶體線上程之間共享。局部變量、方法定義參數 和 異常處理器參數 不會線上程之間共享，它們不會有記憶體可見性問題，也不受記憶體模型的影響。
Java 線程之間的通信由 Java 記憶體模型(JMM)控制。JMM 決定了一個線程對共享變量的寫入何時對另一個線程可見。從抽象的角度來看，JMM 定義了線程與主記憶體之間的抽象關系：線程之間的共享變量存儲在主記憶體中，每一個線程都有一個自己私有的本地記憶體，本地記憶體中存儲了該變量以讀／寫共享變量的副本。本地記憶體是 JMM 的一個抽象概念，并不真實存在。
JMM 抽象示意圖：
從上圖來看，如果線程 A 和線程 B 要通信的話，要如下兩個步驟：
1、線程 A 需要将本地記憶體 A 中的共享變量副本重新整理到主記憶體去
2、線程 B 去主記憶體讀取線程 A 之前已更新過的共享變量
步驟示意圖：
舉個例子：
本地記憶體 A 和 B 有主記憶體共享變量 X 的副本。假設一開始時，這三個記憶體中 X 的值都是 0。線程 A 正執行時，把更新後的 X 值(假設為 1)臨時存放在自己的本地記憶體 A 中。當線程 A 和 B 需要通信時，線程 A 首先會把自己本地記憶體 A 中修改後的 X 值重新整理到主記憶體去，此時主記憶體中的 X 值變為了 1。随後，線程 B 到主記憶體中讀取線程 A 更新後的共享變量 X 的值，此時線程 B 的本地記憶體的 X 值也變成了 1。
整體來看，這兩個步驟實質上是線程 A 再向線程 B 發送消息，而這個通信過程必須經過主記憶體。JMM 通過控制主記憶體與每個線程的本地記憶體之間的互動，來為 Java 程式員提供記憶體可見性保證。
重排序
在執行程式時為了提高性能，編譯器和處理器常常會對指令做重排序。重排序分三類：
1、 編譯器優化的重排序 。編譯器在不改變單線程程式語義的前提下，可以重新安排語句的執行順序。
2、 指令級并行的重排序 。現代處理器采用了指令級并行技術來将多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
3、 記憶體系統的重排序 。由于處理器使用緩存和讀／寫緩沖區，這使得加載和存儲操作看上去可能是在亂序執行。
從 Java 源代碼到最終實際執行的指令序列，會分别經曆下面三種重排序：
上面的這些重排序都可能導緻多線程程式出現記憶體可見性問題。對于編譯器，JMM 的編譯器重排序規則會禁止特定類型的編譯器重排序(不是所有的編譯器重排序都要禁止)。對于處理器重排序，JMM 的處理器重排序規則會要求 Java 編譯器在生成指令序列時，插入特定類型的記憶體屏障指令，通過記憶體屏障指令來禁止特定類型的處理器重排序(不是所有的處理器重排序都要禁止)。
JMM 屬于語言級的記憶體模型，它確定在不同的編譯器和不同的處理器平台之上，通過禁止特定類型的編譯器重排序和處理器重排序，為程式員提供一緻的記憶體可見性保證。
處理器重排序
現代的處理器使用 寫緩沖區 來臨時儲存向記憶體寫入的資料。寫緩沖區可以保證指令流水線持續運作，它可以避免由于處理器停頓下來等待向記憶體寫入資料而産生的延遲。同時，通過以批處理的方式重新整理寫緩沖區，以及合并寫緩沖區中對同一記憶體位址的多次寫，可以減少對記憶體總線的占用。雖然寫緩沖區有這麼多好處，但每個處理器上的寫緩沖區，僅僅對它所在的處理器可見。這個特性會對記憶體操作的執行順序産生重要的影響：處理器對記憶體的讀/寫操作的執行順序，不一定與記憶體實際發生的讀/寫操作順序一緻！
舉個例子：
假設處理器A和處理器B按程式的順序并行執行記憶體通路，最終卻可能得到 x = y = 0。具體的原因如下圖所示：
exam1-ans
處理器 A 和 B 同時把共享變量寫入在寫緩沖區中(A1、B1)，然後再從記憶體中讀取另一個共享變量(A2、B2)，最後才把自己寫緩沖區中儲存的髒資料重新整理到記憶體中(A3、B3)。當以這種時序執行時，程式就可以得到 x = y = 0 的結果。
從記憶體操作實際發生的順序來看，直到處理器 A 執行 A3 來重新整理自己的寫緩存區，寫操作 A1 才算真正執行了。雖然處理器 A 執行記憶體操作的順序為：A1 -> A2，但記憶體操作實際發生的順序卻是：A2 -> A1。此時，處理器 A 的記憶體操作順序被重排序了。
這裡的關鍵是，由于 寫緩沖區僅對自己的處理器可見，它會導緻處理器執行記憶體操作的順序可能會與記憶體實際的操作執行順序不一緻 。由于現代的處理器都會使用寫緩沖區，是以現代的處理器都會允許對寫-讀操作重排序。
記憶體屏障指令
為了保證記憶體可見性，Java 編譯器在生成指令序列的适當位置會插入 記憶體屏障指令 來禁止特定類型的處理器重排序。JMM 把記憶體屏障指令分為下列四類：
happens-before
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 與 JMM 的關系如下圖所示：
如上圖所示，一個 happens-before 規則對應于一個或多個編譯器和處理器重排序規則。
資料依賴性
如果兩個操作通路同一個變量，且這兩個操作中有一個為寫操作，此時這兩個操作之間就存在資料依賴性。資料依賴分下列三種類型：
名稱代碼示例說明寫後讀a = 1; b = a;寫一個變量之後，再讀這個位置。寫後寫a = 1; a = 2;寫一個變量之後，再寫這個變量。讀後寫a = b; b = 1;讀一個變量之後，再寫這個變量。
上面三種情況，隻要重排序兩個操作的執行順序，程式的執行結果将會被改變。
前面提到過，編譯器和處理器可能會對操作做重排序。編譯器和處理器在重排序時，會遵守資料依賴性，編譯器和處理器不會改變存在資料依賴關系的兩個操作的執行順序。
注意，這裡所說的資料依賴性僅針對單個處理器中執行的指令序列和單個線程中執行的操作，不同處理器之間和不同線程之間的資料依賴性不被編譯器和處理器考慮。
as-if-serial 語義
as-if-serial 語義的意思指： 不管怎麼重排序 (編譯器和處理器為了提高并行度)，(單線程) 程式的執行結果不能被改變 。編譯器，runtime 和處理器都必須遵守 as-if-serial 語義。
為了遵守 as-if-serial 編譯器和處理器不會對存在資料依賴關系的操作做重排序，因為這種重排序會改變執行結果。但是如果操作之間沒有資料依賴關系，這些操作就可能被編譯器和處理器重排序。
舉個例子：
上面三個操作的資料依賴關系如下圖所示：
如上圖所示，A 和 C 之間存在資料依賴關系，同時 B 和 C 之間也存在資料依賴關系。是以在最終執行的指令序列中，C 不能被重排序到 A 和 B 的前面(C 排到 A 和 B 的前面，程式的結果将會被改變)。但 A 和 B 之間沒有資料依賴關系，編譯器和處理器可以重排序 A 和 B 之間的執行順序。下圖是該程式的兩種執行順序：
在計算機中，軟體技術和硬體技術有一個共同的目标：在不改變程式執行結果的前提下，盡可能的開發并行度。編譯器和處理器遵從這一目标，從 happens-before 的定義我們可以看出，JMM 同樣遵從這一目标。
重排序對多線程的影響
舉例：
由于操作 1 和 2 沒有資料依賴關系，編譯器和處理器可以對這兩個操作重排序；操作 3 和操作 4 沒有資料依賴關系，編譯器和處理器也可以對這兩個操作重排序。
1、當操作 1 和操作 2 重排序時，可能會産生什麼效果？
如上圖所示，操作 1 和操作 2 做了重排序。程式執行時，線程 A 首先寫标記變量 flag，随後線程 B 讀這個變量。由于條件判斷為真，線程 B 将讀取變量 a。此時，變量 a 還根本沒有被線程 A 寫入，在這裡多線程程式的語義被重排序破壞了！
2、當操作 3 和操作 4 重排序時會産生什麼效果(借助這個重排序，可以順便說明控制依賴性)。
在程式中，操作 3 和操作 4 存在 控制依賴關系 。當代碼中存在控制依賴性時， 會影響指令序列執行的并行度 。為此，編譯器和處理器會采用 猜測 (Speculation)執行來克服控制相關性對并行度的影響。以處理器的猜測執行為例，執行線程 B 的處理器可以提前讀取并計算 a * a，然後把計算結果臨時儲存到一個名為重排序緩沖(reorder buffer ROB)的硬體緩存中。當接下來操作 3 的條件判斷為真時，就把該計算結果寫入變量 i 中。
從圖中我們可以看出，猜測執行實質上對操作3和4做了重排序。重排序在這裡破壞了多線程程式的語義！
在單線程程式中，對存在控制依賴的操作重排序，不會改變執行結果(這也是 as-if-serial 語義允許對存在控制依賴的操作做重排序的原因)；但在多線程程式中，對存在控制依賴的操作重排序，可能會改變程式的執行結果。
順序一緻性
順序一緻性記憶體模型
順序一緻性記憶體模型有兩大特性：
- 一個線程中的所有操作必須按照程式的順序來執行。
- (不管程式是否同步)所有線程都隻能看到一個單一的操作執行順序。在順序一緻性記憶體模型中，每個操作都必須原子執行且立刻對所有線程可見。
順序一緻性記憶體模型為程式員提供的視圖如下：
在概念上，順序一緻性模型有一個單一的全局記憶體，這個記憶體通過一個左右擺動的開關可以連接配接到任意一個線程，同時每一個線程必須按照程式的順序來執行記憶體讀/寫操作。從上面的示意圖我們可以看出，在任意時間點最多隻能有一個線程可以連接配接到記憶體。當多個線程并發執行時，圖中的開關裝置能把所有線程的所有記憶體讀/寫操作串行化。
舉個例子：
假設有兩個線程 A 和 B 并發執行。其中 A 線程有三個操作，它們在程式中的順序是：A1 -> A2 -> A3。B 線程也有三個操作，它們在程式中的順序是：B1 -> B2 -> B3。
假設這兩個線程使用螢幕鎖來正确同步：A 線程的三個操作執行後釋放螢幕鎖，随後 B 線程擷取同一個螢幕鎖。那麼程式在順序一緻性模型中的執行效果将如下圖所示：
現在我們再假設這兩個線程沒有做同步，下面是這個未同步程式在順序一緻性模型中的執行示意圖：
未同步程式在順序一緻性模型中雖然整體執行順序是無序的，但所有線程都隻能看到一個一緻的整體執行順序。以上圖為例，線程 A 和 B 看到的執行順序都是：B1 -> A1 -> A2 -> B2 -> A3 -> B3。之是以能得到這個保證是因為順序一緻性記憶體模型中的每個操作必須立即對任意線程可見。
但是，在 JMM 中就沒有這個保證。未同步程式在 JMM 中不但整體的執行順序是無序的，而且所有線程看到的操作執行順序也可能不一緻。比如，在目前線程把寫過的資料緩存在本地記憶體中，在還沒有重新整理到主記憶體之前，這個寫操作僅對目前線程可見；從其他線程的角度來觀察，會認為這個寫操作根本還沒有被目前線程執行。隻有目前線程把本地記憶體中寫過的資料重新整理到主記憶體之後，這個寫操作才能對其他線程可見。在這種情況下，目前線程和其它線程看到的操作執行順序将不一緻。
同步程式的順序一緻性效果
下面我們對前面的示例程式用鎖來同步，看看正确同步的程式如何具有順序一緻性。
請看下面的示例代碼：
上面示例代碼中，假設 A 線程執行 write() 方法後，B 線程執行 reade() 方法。這是一個正确同步的多線程程式。根據JMM規範，該程式的執行結果将與該程式在順序一緻性模型中的執行結果相同。下面是該程式在兩個記憶體模型中的執行時序對比圖：
在順序一緻性模型中，所有操作完全按程式的順序執行。而在 JMM 中，臨界區内的代碼可以重排序(但 JMM 不允許臨界區内的代碼“逸出”到臨界區之外，那樣會破壞螢幕的語義)。JMM 會在退出臨界區和進入臨界區這兩個關鍵時間點做一些特别處理，使得線程在這兩個時間點具有與順序一緻性模型相同的記憶體視圖。雖然線程 A 在臨界區内做了重排序，但由于螢幕的互斥執行的特性，這裡的線程 B 根本無法“觀察”到線程 A 在臨界區内的重排序。這種重排序既提高了執行效率，又沒有改變程式的執行結果。
從這裡我們可以看到 JMM 在具體實作上的基本方針：在不改變(正确同步的)程式執行結果的前提下，盡可能的為編譯器和處理器的優化打開友善之門。
未同步程式的執行特性
未同步程式在 JMM 中的執行時，整體上是無序的，其執行結果無法預知。未同步程式在兩個模型中的執行特性有下面幾個差異：
第三個差異與處理器總線的工作機制密切相關。在計算機中，資料通過總線在處理器和記憶體之間傳遞。每次處理器和記憶體之間的資料傳遞都是通過 總線事務 來完成的。總線事務包括讀事務和寫事務。讀事務從記憶體傳送資料到處理器，寫事務從處理器傳遞資料到記憶體，每個事務會讀／寫記憶體中一個或多個實體上連續的字。總線會同步試圖并發使用總線的事務。在一個處理器執行總線事務期間，總線會禁止其它所有的處理器和 I／O 裝置執行記憶體的讀／寫。
總線的工作機制：
如上圖所示，假設處理器 A、B、和 C 同時向總線發起總線事務，這時總線仲裁會對競争作出裁決，假設總線在仲裁後判定處理器 A 在競争中獲勝(總線仲裁會確定所有處理器都能公平的通路記憶體)。此時處理器 A 繼續它的總線事務，而其它兩個處理器則要等待處理器 A 的總線事務完成後才能開始再次執行記憶體通路。假設在處理器 A 執行總線事務期間(不管這個總線事務是讀事務還是寫事務)，處理器 D 向總線發起了總線事務，此時處理器 D 的這個請求會被總線禁止。
總線的這些工作機制可以 把所有處理器對記憶體的通路以串行化的方式來執行 ； 在任意時間點，最多隻能有一個處理器能通路記憶體 。這個特性 確定了單個總線事務之中的記憶體讀/寫操作具有原子性 。
在一些 32 位的處理器上，如果要求對 64 位資料的寫操作具有原子性，會有比較大的開銷。為了照顧這種處理器，Java 語言規範鼓勵但不強求 JVM 對 64 位的 long 型變量和 double 型變量的寫具有原子性。當 JVM 在這種處理器上運作時，會把一個 64 位 long/ double 型變量的寫操作拆分為兩個 32 位的寫操作來執行。這兩個 32 位的寫操作可能會被配置設定到不同的總線事務中執行，此時對這個 64 位變量的寫将不具有原子性。
當單個記憶體操作不具有原子性，将可能會産生意想不到後果。請看下面示意圖：
如上圖所示，假設處理器 A 寫一個 long 型變量，同時處理器 B 要讀這個 long 型變量。處理器 A 中 64 位的寫操作被拆分為兩個 32 位的寫操作，且這兩個 32 位的寫操作被配置設定到不同的寫事務中執行。同時處理器 B 中 64 位的讀操作被配置設定到單個的讀事務中執行。當處理器 A 和 B 按上圖的時序來執行時，處理器 B 将看到僅僅被處理器 A “寫了一半“的無效值。
注意，在 JSR -133 之前的舊記憶體模型中，一個 64 位 long/ double 型變量的 讀/寫 操作可以被拆分為兩個 32 位的讀/寫操作來執行。從 JSR -133 記憶體模型開始(即從JDK5開始)，僅僅隻允許把一個 64 位 long/ double 型變量的 寫 操作拆分為兩個 32 位的寫操作來執行， 任意的讀操作在JSR -133中都必須具有原子性 (即任意讀操作必須要在單個讀事務中執行)。
Volatile
Volatile 特性
舉個例子：
假設有多個線程分别調用上面程式的三個方法，這個程式在語義上和下面程式等價：
如上面示例程式所示，對一個 volatile 變量的單個讀/寫操作，與對一個普通變量的讀/寫操作使用同一個鎖來同步，它們之間的執行效果相同。
鎖的 happens-before 規則保證釋放鎖和擷取鎖的兩個線程之間的記憶體可見性，這意味着 對一個 volatile 變量的讀，總是能看到(任意線程)對這個 volatile 變量最後的寫入 。
鎖的語義決定了臨界區代碼的執行具有原子性。這意味着即使是 64 位的 long 型和 double 型變量，隻要它是 volatile變量，對該變量的讀寫就将具有原子性。 如果是多個 volatile 操作或類似于 volatile++ 這種複合操作，這些操作整體上不具有原子性 。
簡而言之，volatile 變量自身具有下列特性：
- 可見性。對一個 volatile 變量的讀，總是能看到(任意線程)對這個 volatile 變量最後的寫入。
- 原子性：對任意單個 volatile 變量的讀/寫具有原子性，但類似于 volatile++ 這種複合操作不具有原子性。
volatile 寫-讀的記憶體定義
- 當 寫 一個 volatile 變量時，JMM 會把該線程對應的本地記憶體中的共享變量值重新整理到主記憶體。
- 當 讀 一個 volatile 變量時，JMM 會把該線程對應的本地記憶體置為無效。線程接下來将從主記憶體中讀取共享變量。
假設上面的程式 flag 變量用 volatile 修飾
volatile 記憶體語義的實作
下面是 JMM 針對編譯器制定的 volatile 重排序規則表：
為了實作 volatile 的記憶體語義，編譯器在生成位元組碼時，會在指令序列中插入記憶體屏障來禁止特定類型的處理器重排序。
下面是基于保守政策的 JMM 記憶體屏障插入政策：
- 在每個 volatile 寫操作的前面插入一個 StoreStore 屏障。
- 在每個 volatile 寫操作的後面插入一個 StoreLoad 屏障。
- 在每個 volatile 讀操作的後面插入一個 LoadLoad 屏障。
- 在每個 volatile 讀操作的後面插入一個 LoadStore 屏障。
下面是保守政策下，volatile 寫操作 插入記憶體屏障後生成的指令序列示意圖：
下面是在保守政策下，volatile 讀操作 插入記憶體屏障後生成的指令序列示意圖：
上述 volatile 寫操作和 volatile 讀操作的記憶體屏障插入政策非常保守。在實際執行時，隻要不改變 volatile 寫-讀的記憶體語義，編譯器可以根據具體情況省略不必要的屏障。
鎖
鎖釋放和擷取的記憶體語義
當線程釋放鎖時，JMM 會把該線程對應的本地記憶體中的共享變量重新整理到主記憶體中。
當線程擷取鎖時，JMM 會把該線程對應的本地記憶體置為無效。進而使得被螢幕保護的臨界區代碼必須要從主記憶體中去讀取共享變量。
鎖記憶體語義的實作
借助 ReentrantLock 來講解，PS：後面專門講下這塊(ReentrantLock、Synchronized、公平鎖、非公平鎖、AQS等)，可以看看大明哥的部落格：[http://cmsblogs.com/?p=2210]()
concurrent 包的實作
如果我們仔細分析 concurrent 包的源代碼實作，會發現一個通用化的實作模式：
AQS，非阻塞資料結構和原子變量類(java.util.concurrent.atomic 包中的類)，這些 concurrent 包中的基礎類都是使用這種模式來實作的，而 concurrent 包中的高層類又是依賴于這些基礎類來實作的。從整體來看，concurrent 包的實作示意圖如下：
final
對于 final 域，編譯器和處理器要遵守兩個重排序規則：
寫 final 域的重排序規則
寫 final 域的重排序規則禁止把 final 域的寫重排序到構造函數之外。這個規則的實作包含下面2個方面：
- JMM 禁止編譯器把 final 域的寫重排序到構造函數之外。
- 編譯器會在 final 域的寫之後，構造函數 return 之前，插入一個 StoreStore 屏障。這個屏障禁止處理器把 final 域的寫重排序到構造函數之外。
讀 final 域的重排序規則
在一個線程中，初次讀對象引用與初次讀該對象包含的 final 域，JMM 禁止處理器重排序這兩個操作(注意，這個規則僅僅針對處理器)。編譯器會在讀 final 域操作的前面插入一個 LoadLoad 屏障。
final 域是引用類型
對于引用類型，寫 final 域的重排序規則對編譯器和處理器增加了如下限制：
在構造函數内對一個 final 引用的對象的成員域的寫入，與随後在構造函數外把這個被構造對象的引用指派給一個引用變量，這兩個操作之間不能重排序。
總結
JMM，處理器記憶體模型與順序一緻性記憶體模型之間的關系
JMM 是一個語言級的記憶體模型，處理器記憶體模型是硬體級的記憶體模型，順序一緻性記憶體模型是一個理論參考模型。下面是語言記憶體模型，處理器記憶體模型和順序一緻性記憶體模型的強弱對比示意圖：
JMM 的設計示意圖
JMM 的記憶體可見性保證
Java 程式的記憶體可見性保證按程式類型可以分為下列三類：
1.單線程程式。單線程程式不會出現記憶體可見性問題。編譯器，runtime 和處理器會共同確定單線程程式的執行結果與該程式在順序一緻性模型中的執行結果相同。
2.正确同步的多線程程式。正确同步的多線程程式的執行将具有順序一緻性(程式的執行結果與該程式在順序一緻性記憶體模型中的執行結果相同)。這是 JMM 關注的重點，JMM通過限制編譯器和處理器的重排序來為程式員提供記憶體可見性保證。
3.未同步/未正确同步的多線程程式。JMM 為它們提供了最小安全性保障：線程執行時讀取到的值，要麼是之前某個線程寫入的值，要麼是預設值(0，null，false)。
下圖展示了這三類程式在 JMM 中與在順序一緻性記憶體模型中的執行結果的異同：