來源：http://www.cnblogs.com/nexiyi/p/java_memory_model_and_thread.html
來源：http://www.infoq.com/cn/articles/java-memory-model-1
都寫得不錯，在此對兩篇文章做了簡單的合并。
1. 概述
多任務和高并發是衡量一台計算機處理器的能力重要名額之一。一般衡量一個伺服器性能的高低好壞，使用每秒事務處理數（Transactions Per Second，TPS）這個名額比較能說明問題，它代表着一秒内伺服器平均能響應的請求數，而TPS值與程式的并發能力有着非常密切的關系。在讨論Java記憶體模型和線程之前，先簡單介紹一下硬體的效率與一緻性。
2.硬體的效率與一緻性
由于計算機的儲存設備與處理器的運算能力之間有幾個數量級的差距，是以現代計算機系統都不得不加入一層讀寫速度盡可能接近處理器運算速度的高速緩存（cache）來作為記憶體與處理器之間的緩沖：将運算需要使用到的資料複制到緩存中，讓運算能快速進行，當運算結束後再從緩存同步回記憶體之中沒這樣處理器就無需等待緩慢的記憶體讀寫了。
基于高速緩存的存儲互動很好地解決了處理器與記憶體的速度沖突，但是引入了一個新的問題：緩存一緻性（Cache Coherence）。在多處理器系統中，每個處理器都有自己的高速緩存，而他們又共享同一主存，如下圖所示：多個處理器運算任務都涉及同一塊主存，需要一種協定可以保障資料的一緻性，這類協定有MSI、MESI、MOSI及Dragon Protocol等。Java虛拟機記憶體模型中定義的記憶體通路操作與硬體的緩存通路操作是具有可比性的，後續将介紹Java記憶體模型。
除此之外，為了使得處理器内部的運算單元能竟可能被充分利用，處理器可能會對輸入代碼進行亂起執行（Out-Of-Order Execution）優化，處理器會在計算之後将對亂序執行的代碼進行結果重組，保證結果準确性。與處理器的亂序執行優化類似，Java虛拟機的即時編譯器中也有類似的指令重排序（Instruction Recorder）優化。
3.Java記憶體模型
定義Java記憶體模型并不是一件容易的事情，這個模型必須定義得足夠嚴謹，才能讓Java的并發操作不會産生歧義；但是，也必須得足夠寬松，使得虛拟機的實作能有足夠的自由空間去利用硬體的各種特性（寄存器、高速緩存等）來擷取更好的執行速度。經過長時間的驗證和修補，在JDK1.5釋出後，Java記憶體模型就已經成熟和完善起來了。
3.1 主記憶體與工作記憶體
Java記憶體模型的主要目标是定義程式中各個變量的通路規則，即在虛拟機中将變量存儲到記憶體和從記憶體中取出變量這樣底層細節。此處的變量與Java程式設計時所說的變量不一樣，指包括了執行個體字段、靜态字段和構成數組對象的元素，但是不包括局部變量與方法參數，後者是線程私有的，不會被共享。
Java記憶體模型中規定了所有的變量都存儲在主記憶體中，每條線程還有自己的工作記憶體（可以與前面将的處理器的高速緩存類比），線程的工作記憶體中儲存了該線程使用到的變量到主記憶體副本拷貝，線程對變量的所有操作（讀取、指派）都必須在工作記憶體中進行，而不能直接讀寫主記憶體中的變量。不同線程之間無法直接通路對方工作記憶體中的變量，線程間變量值的傳遞均需要在主記憶體來完成，線程、主記憶體和工作記憶體的互動關系如下圖所示，和上圖很類似。
這裡的主記憶體、工作記憶體與Java記憶體區域的Java堆、棧、方法區不是同一層次記憶體劃分。
進一步解析上圖，在java中，所有執行個體域、靜态域和數組元素存儲在堆記憶體中，堆記憶體線上程之間共享（“共享變量”代指執行個體域，靜态域和數組元素）。局部變量（Local variables），方法定義參數（java語言規範稱之為formal method parameters）和異常處理器參數（exception handler parameters）不會線上程之間共享，它們不會有記憶體可見性問題，也不受記憶體模型的影響。
Java線程之間的通信由Java記憶體模型（本文簡稱為JMM）控制，JMM決定一個線程對共享變量的寫入何時對另一個線程可見。從抽象的角度來看，JMM定義了線程和主記憶體之間的抽象關系：線程之間的共享變量存儲在主記憶體（main memory）中，每個線程都有一個私有的本地記憶體（local memory），本地記憶體中存儲了該線程以讀/寫共享變量的副本。本地記憶體是JMM的一個抽象概念，并不真實存在。它涵蓋了緩存，寫緩沖區，寄存器以及其他的硬體和編譯器優化。
Java記憶體模型的抽象示意圖如下：
3.2 記憶體間互動操作
在并發程式設計中，我們需要處理兩個關鍵問題：線程之間如何通信及線程之間如何同步（這裡的線程是指并發執行的活動實體）。通信是指線程之間以何種機制來交換資訊。在指令式程式設計中，線程之間的通信機制有兩種：共享記憶體和消息傳遞。
在共享記憶體的并發模型裡，線程之間共享程式的公共狀态，線程之間通過寫-讀記憶體中的公共狀态來隐式進行通信。在消息傳遞的并發模型裡，線程之間沒有公共狀态，線程之間必須通過明确的發送消息來顯式進行通信。
同步是指程式用于控制不同線程之間操作發生相對順序的機制。在共享記憶體并發模型裡，同步是顯式進行的。程式員必須顯式指定某個方法或某段代碼需要線上程之間互斥執行。在消息傳遞的并發模型裡，由于消息的發送必須在消息的接收之前，是以同步是隐式進行的。Java的并發采用的是共享記憶體模型，Java線程之間的通信總是隐式進行，整個通信過程對程式員完全透明。
從上圖來看，線程A與線程B之間如要通信的話，必須要經曆下面2個步驟：
- 首先，線程A把本地記憶體A中更新過的共享變量重新整理到主記憶體中去。
- 然後，線程B到主記憶體中去讀取線程A之前已更新過的共享變量。
下面通過示意圖來說明這兩個步驟：
如上圖所示，本地記憶體A和B有主記憶體中共享變量x的副本。假設初始時，這三個記憶體中的x值都為0。線程A在執行時，把更新後的x值（假設值為1）臨時存放在自己的本地記憶體A中。當線程A和線程B需要通信時，線程A首先會把自己本地記憶體中修改後的x值重新整理到主記憶體中，此時主記憶體中的x值變為了1。随後，線程B到主記憶體中去讀取線程A更新後的x值，此時線程B的本地記憶體的x值也變為了1。
從整體來看，這兩個步驟實質上是線程A在向線程B發送消息，而且這個通信過程必須要經過主記憶體。JMM通過控制主記憶體與每個線程的本地記憶體之間的互動，來為java程式員提供記憶體可見性保證。
關于主記憶體與工作記憶體之間的具體互動協定，即一個變量如何從主記憶體拷貝到工作記憶體、如何從工作記憶體同步到主記憶體之間的實作細節，Java記憶體模型定義了以下八種操作來完成：
- lock（鎖定）：作用于主記憶體的變量，把一個變量辨別為一條線程獨占狀态。
- unlock（解鎖）：作用于主記憶體變量，把一個處于鎖定狀态的變量釋放出來，釋放後的變量才可以被其他線程鎖定。
- read（讀取）：作用于主記憶體變量，把一個變量值從主記憶體傳輸到線程的工作記憶體中，以便随後的load動作使用
- load（載入）：作用于工作記憶體的變量，它把read操作從主記憶體中得到的變量值放入工作記憶體的變量副本中。
- use（使用）：作用于工作記憶體的變量，把工作記憶體中的一個變量值傳遞給執行引擎，每當虛拟機遇到一個需要使用變量的值的位元組碼指令時将會執行這個操作。
- assign（指派）：作用于工作記憶體的變量，它把一個從執行引擎接收到的值指派給工作記憶體的變量，每當虛拟機遇到一個給變量指派的位元組碼指令時執行這個操作。
- store（存儲）：作用于工作記憶體的變量，把工作記憶體中的一個變量的值傳送到主記憶體中，以便随後的write的操作。
- write（寫入）：作用于主記憶體的變量，它把store操作從工作記憶體中一個變量的值傳送到主記憶體的變量中。
如果要把一個變量從主記憶體中複制到工作記憶體，就需要按順尋地執行read和load操作，如果把變量從工作記憶體中同步回主記憶體中，就要按順序地執行store和write操作。Java記憶體模型隻要求上述操作必須按順序執行，而沒有保證必須是連續執行。也就是read和load之間，store和write之間是可以插入其他指令的，如對主記憶體中的變量a、b進行通路時，可能的順序是read a，read b，load b， load a。Java記憶體模型還規定了在執行上述八種基本操作時，必須滿足如下規則：
- 不允許read和load、store和write操作之一單獨出現
- 不允許一個線程丢棄它的最近assign的操作，即變量在工作記憶體中改變了之後必須同步到主記憶體中。
- 不允許一個線程無原因地（沒有發生過任何assign操作）把資料從工作記憶體同步回主記憶體中。
- 一個新的變量隻能在主記憶體中誕生，不允許在工作記憶體中直接使用一個未被初始化（load或assign）的變量。即就是對一個變量實施use和store操作之前，不許先執行過了assign和load操作。
- 一個變量在同一時刻隻允許一條線成對其進行lock操作，lock和unlock必須成對出現
- 如果對一個變量執行lock操作，将會清空工作記憶體中此變量的值，在執行引擎使用這個變量前需要重新執行load或assign操作初始化變量的值
- 如果一個變量事先沒有被lock操作鎖定，則不允許對它執行unlock操作；也不允許去unlock一個被其他線程鎖定的變量。
- 對一個變量執行unlock操作之前，必須先把次變量同步到主記憶體中（執行store和write操作）。
3.3 重排序
在執行程式時為了提高性能，編譯器和處理器經常會對指令進行重排序。重排序分成三種類型：
- 編譯器優化的重排序。編譯器在不改變單線程程式語義放入前提下，可以重新安排語句的執行順序。
- 指令級并行的重排序。現代處理器采用了指令級并行技術來将多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
- 記憶體系統的重排序。由于處理器使用緩存和讀寫緩沖區，這使得加載和存儲操作看上去可能是在亂序執行。
從Java源代碼到最終實際執行的指令序列，會經過下面三種重排序：
上述的1屬于編譯器重排序，2和3屬于處理器重排序。這些重排序都可能會導緻多線程程式出現記憶體可見性問題。對于編譯器，JMM的編譯器重排序規則會禁止特定類型的編譯器重排序（不是所有的編譯器重排序都要禁止）。對于處理器重排序，JMM的處理器重排序規則會要求java編譯器在生成指令序列時，插入特定類型的記憶體屏障（memory barriers，intel稱之為memory fence）指令，通過記憶體屏障指令來禁止特定類型的處理器重排序（不是所有的處理器重排序都要禁止）。
JMM屬于語言級的記憶體模型，它確定在不同的編譯器和不同的處理器平台之上，通過禁止特定類型的編譯器重排序和處理器重排序，為程式員提供一緻的記憶體可見性保證。
處理器重排序，現代的處理器使用寫緩沖區來臨時儲存向記憶體寫入的資料。寫緩沖區可以保證指令流水線持續運作，它可以避免由于處理器停頓下來等待向記憶體寫入資料而産生的延遲。同時，通過以批處理的方式重新整理寫緩沖區，以及合并寫緩沖區中對同一記憶體位址的多次寫，可以減少對記憶體總線的占用。雖然寫緩沖區有這麼多好處，但每個處理器上的寫緩沖區，僅僅對它所在的處理器可見。這個特性會對記憶體操作的執行順序産生重要的影響：處理器對記憶體的讀/寫操作的執行順序，不一定與記憶體實際發生的讀/寫操作順序一緻！為了具體說明，請看下面示例：
| Processor A | Processor B |
|---|---|
| a = 1; //A1 x = b; //A2 | b = 2; //B1 y = a; //B2 |
| 初始狀态：a = b = 0 處理器允許執行後得到結果：x = y = 0 |
假設處理器A和處理器B按程式的順序并行執行記憶體通路，最終卻可能得到x = y = 0的結果。具體的原因如下圖所示：
這裡處理器A和處理器B可以同時把共享變量寫入自己的寫緩沖區（A1，B1），然後從記憶體中讀取另一個共享變量（A2，B2），最後才把自己寫緩存區中儲存的髒資料重新整理到記憶體中（A3，B3）。當以這種時序執行時，程式就可以得到x = y = 0的結果。
從記憶體操作實際發生的順序來看，直到處理器A執行A3來重新整理自己的寫緩存區，寫操作A1才算真正執行了。雖然處理器A執行記憶體操作的順序為：A1->A2，但記憶體操作實際發生的順序卻是：A2->A1。此時，處理器A的記憶體操作順序被重排序了（處理器B的情況和處理器A一樣，這裡就不贅述了）。
這裡的關鍵是，由于寫緩沖區僅對自己的處理器可見，它會導緻處理器執行記憶體操作的順序可能會與記憶體實際的操作執行順序不一緻。由于現代的處理器都會使用寫緩沖區，是以現代的處理器都會允許對寫-讀操做重排序。
下面是常見處理器允許的重排序類型的清單：
| Load-Load | Load-Store | Store-Store | Store-Load | 資料依賴 | |
| sparc-TSO | N | N | N | Y | N |
| x86 | N | N | N | Y | N |
| ia64 | Y | Y | Y | Y | N |
| PowerPC | Y | Y | Y | Y | N |
上表單元格中的“N”表示處理器不允許兩個操作重排序，“Y”表示允許重排序。
從上表我們可以看出：常見的處理器都允許Store-Load重排序；常見的處理器都不允許對存在資料依賴的操作做重排序。sparc-TSO和x86擁有相對較強的處理器記憶體模型，它們僅允許對寫-讀操作做重排序（因為它們都使用了寫緩沖區）。
※注1：sparc-TSO是指以TSO(Total Store Order)記憶體模型運作時，sparc處理器的特性。
※注2：上表中的x86包括x64及AMD64。
※注3：由于ARM處理器的記憶體模型與PowerPC處理器的記憶體模型非常類似，本文将忽略它。
※注4：資料依賴性後文會專門說明。
為了保證記憶體的可見性，Java編譯器在生成指令序列的适當位置會插入記憶體屏障指令來禁止特定類型的處理器重排序。Java記憶體模型把記憶體屏障分為LoadLoad、LoadStore、StoreLoad和StoreStore四種：
StoreLoad Barriers是一個“全能型”的屏障，它同時具有其他三個屏障的效果。現代的多處理器大都支援該屏障（其他類型的屏障不一定被所有處理器支援）。執行該屏障開銷會很昂貴，因為目前處理器通常要把寫緩沖區中的資料全部重新整理到記憶體中（buffer fully flush）。
happens-before，從JDK5開始，java使用新的JSR -133記憶體模型（這裡針對的都是JSR- 133記憶體模型）。JSR-133提出了happens-before的概念，通過這個概念來闡述操作之間的記憶體可見性。如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必須存在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的關系如下圖所示：
如上圖所示，一個happens-before規則通常對應于多個編譯器重排序規則和處理器重排序規則。對于java程式員來說，happens-before規則簡單易懂，它避免程式員為了了解JMM提供的記憶體可見性保證而去學習複雜的重排序規則以及這些規則的具體實作。