基礎
併發編程的模型分類
在併發編程須要處理的兩個關鍵問題是：線程之間如何通訊 和 線程之間如何同步。java
通訊
通訊 是指線程之間以何種機制來交換信息。在命令式編程中，線程之間的通訊機制有兩種：共享內存 和 消息傳遞。程序員
在共享內存的併發模型裏，線程之間共享程序的公共狀態，線程之間經過寫-讀內存中的公共狀態來隱式進行通訊。編程
在消息傳遞的併發模型裏，線程之間沒有公共狀態，線程之間必須經過明確的發送消息來顯式進行通訊。數組
同步
同步 是指程序用於控制不一樣線程之間操做發生相對順序的機制。緩存
在共享內存的併發模型裏，同步是顯式進行的。程序員必須顯式指定某個方法或某段代碼須要在線程之間互斥執行。安全
在消息傳遞的併發模型裏，因爲消息的發送必須在消息的接收以前，所以同步是隱式進行的。微信
Java 的併發採用的是共享內存模型，Java 線程之間的通訊老是隱式進行，整個通訊過程對程序員徹底透明。數據結構
JAVA 內存模型的抽象
在 Java 中，全部實例域、靜態域 和 數組元素存儲在堆內存中，堆內存在線程之間共享。局部變量、方法定義參數 和 異常處理器參數 不會在線程之間共享，它們不會有內存可見性問題，也不受內存模型的影響。多線程
Java 線程之間的通訊由 Java 內存模型（JMM）控制。JMM 決定了一個線程對共享變量的寫入什麼時候對另外一個線程可見。從抽象的角度來看，JMM 定義了線程與主內存之間的抽象關係：線程之間的共享變量存儲在主內存中，每個線程都有一個本身私有的本地內存，本地內存中存儲了該變量以讀／寫共享變量的副本。本地內存是 JMM 的一個抽象概念，並不真實存在。併發
JMM 抽象示意圖：
從上圖來看，若是線程 A 和線程 B 要通訊的話，要以下兩個步驟：
一、線程 A 須要將本地內存 A 中的共享變量副本刷新到主內存去
二、線程 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 程序員提供內存可見性保證。
重排序
在執行程序時爲了提升性能，編譯器和處理器經常會對指令作重排序。重排序分三類：
一、編譯器優化的重排序。編譯器在不改變單線程程序語義的前提下，能夠從新安排語句的執行順序。
二、指令級並行的重排序。現代處理器採用了指令級並行技術來將多條指令重疊執行。若是不存在數據依賴性，處理器能夠改變語句對應機器指令的執行順序。
三、內存系統的重排序。因爲處理器使用緩存和讀／寫緩衝區，這使得加載和存儲操做看上去多是在亂序執行。
從 Java 源代碼到最終實際執行的指令序列，會分別經歷下面三種重排序：
上面的這些重排序均可能致使多線程程序出現內存可見性問題。對於編譯器，JMM 的編譯器重排序規則會禁止特定類型的編譯器重排序（不是全部的編譯器重排序都要禁止）。對於處理器重排序，JMM 的處理器重排序規則會要求 Java 編譯器在生成指令序列時，插入特定類型的內存屏障指令，經過內存屏障指令來禁止特定類型的處理器重排序（不是全部的處理器重排序都要禁止）。
JMM 屬於語言級的內存模型，它確保在不一樣的編譯器和不一樣的處理器平臺之上，經過禁止特定類型的編譯器重排序和處理器重排序，爲程序員提供一致的內存可見性保證。
處理器重排序
現代的處理器使用寫緩衝區來臨時保存向內存寫入的數據。寫緩衝區能夠保證指令流水線持續運行，它能夠避免因爲處理器停頓下來等待向內存寫入數據而產生的延遲。同時，經過以批處理的方式刷新寫緩衝區，以及合併寫緩衝區中對同一內存地址的屢次寫，能夠減小對內存總線的佔用。雖然寫緩衝區有這麼多好處，但每一個處理器上的寫緩衝區，僅僅對它所在的處理器可見。這個特性會對內存操做的執行順序產生重要的影響：處理器對內存的讀/寫操做的執行順序，不必定與內存實際發生的讀/寫操做順序一致！
舉個例子：
假設處理器A和處理器B按程序的順序並行執行內存訪問，最終卻可能獲得 x = y = 0。具體的緣由以下圖所示：
處理器 A 和 B 同時把共享變量寫入在寫緩衝區中（A一、B1），而後再從內存中讀取另外一個共享變量（A二、B2），最後才把本身寫緩衝區中保存的髒數據刷新到內存中（A三、B3）。當以這種時序執行時，程序就能夠獲得 x = y = 0 的結果。
從內存操做實際發生的順序來看，直處處理器 A 執行 A3 來刷新本身的寫緩存區，寫操做 A1 纔算真正執行了。雖然處理器 A 執行內存操做的順序爲：A1 -> A2，但內存操做實際發生的順序倒是：A2 -> A1。此時，處理器 A 的內存操做順序被重排序了。
這裏的關鍵是，因爲寫緩衝區僅對本身的處理器可見，它會致使處理器執行內存操做的順序可能會與內存實際的操做執行順序不一致。因爲現代的處理器都會使用寫緩衝區，所以現代的處理器都會容許對寫-讀操做重排序。
內存屏障指令
爲了保證內存可見性，Java 編譯器在生成指令序列的適當位置會插入內存屏障指令來禁止特定類型的處理器重排序。JMM 把內存屏障指令分爲下列四類：
| 屏障類型 | 指令示例 | 說明 |
|---|---|---|
| LoadLoad Barriers | Load1; LoadLoad; Load2 | 確保 Load1 數據的裝載，以前於 Load2 及全部後續裝載指令的裝載。 |
| StoreStore Barriers | Store1; StoreStore; Store2 | 確保 Store1 數據對其餘處理器可見（刷新到內存），以前於 Store2 及全部後續存儲指令的存儲。 |
| LoadStore Barriers | Load1; LoadStore; Store2 | 確保 Load1 數據裝載，以前於 Store2 及全部後續的存儲指令刷新到內存。 |
| StoreLoad Barriers | Store1; StoreLoad; Load2 | 確保 Store1 數據對其餘處理器變得可見（指刷新到內存），以前於 Load2 及全部後續裝載指令的裝載。StoreLoadBarriers 會使該屏障以前的全部內存訪問指令（存儲和裝載指令）完成以後，才執行該屏障以後的內存訪問指令。 |
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 編譯器和處理器不會對存在數據依賴關係的操做作重排序，由於這種重排序會改變執行結果。可是若是操做之間沒有數據依賴關係，這些操做就可能被編譯器和處理器重排序。
舉個例子：
|
1
2
3
|
double
pi =
3.14
;
//A
double
r =
1.0
;
//B
double
area = pi * r * r;
//C
|
上面三個操做的數據依賴關係以下圖所示：
如上圖所示，A 和 C 之間存在數據依賴關係，同時 B 和 C 之間也存在數據依賴關係。所以在最終執行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的結果將會被改變）。但 A 和 B 之間沒有數據依賴關係，編譯器和處理器能夠重排序 A 和 B 之間的執行順序。下圖是該程序的兩種執行順序：
在計算機中，軟件技術和硬件技術有一個共同的目標：在不改變程序執行結果的前提下，儘量的開發並行度。編譯器和處理器聽從這一目標，從 happens-before 的定義咱們能夠看出，JMM 一樣聽從這一目標。
重排序對多線程的影響
舉例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
class
Demo {
int
a =
0
;
boolean
flag =
false
;
public
void
write() {
a =
1
;
//1
flag =
true
;
//2
}
public
void
read() {
if
(flag) {
//3
int
i = a * a;
//4
}
}
}
|
因爲操做 1 和 2 沒有數據依賴關係，編譯器和處理器能夠對這兩個操做重排序；操做 3 和操做 4 沒有數據依賴關係，編譯器和處理器也能夠對這兩個操做重排序。
一、當操做 1 和操做 2 重排序時，可能會產生什麼效果？
如上圖所示，操做 1 和操做 2 作了重排序。程序執行時，線程 A 首先寫標記變量 flag，隨後線程 B 讀這個變量。因爲條件判斷爲真，線程 B 將讀取變量 a。此時，變量 a 還根本沒有被線程 A 寫入，在這裏多線程程序的語義被重排序破壞了！
二、當操做 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 中不但總體的執行順序是無序的，並且全部線程看到的操做執行順序也可能不一致。好比，在當前線程把寫過的數據緩存在本地內存中，在尚未刷新到主內存以前，這個寫操做僅對當前線程可見；從其餘線程的角度來觀察，會認爲這個寫操做根本尚未被當前線程執行。只有當前線程把本地內存中寫過的數據刷新到主內存以後，這個寫操做才能對其餘線程可見。在這種狀況下，當前線程和其它線程看到的操做執行順序將不一致。
同步程序的順序一致性效果
下面咱們對前面的示例程序用鎖來同步，看看正確同步的程序如何具備順序一致性。
請看下面的示例代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
class
demo {
int
a =
0
;
boolean
flag =
false
;
public
synchronized
void
write() {
//獲取鎖
a =
1
;
flag =
true
;
}
//釋放鎖
public
synchronized
void
read() {
//獲取鎖
if
(flag) {
int
i = a;
}
}
//釋放鎖
}
|
上面示例代碼中，假設 A 線程執行 write() 方法後，B 線程執行 reade() 方法。這是一個正確同步的多線程程序。根據JMM規範，該程序的執行結果將與該程序在順序一致性模型中的執行結果相同。下面是該程序在兩個內存模型中的執行時序對比圖：
在順序一致性模型中，全部操做徹底按程序的順序執行。而在 JMM 中，臨界區內的代碼能夠重排序（但 JMM 不容許臨界區內的代碼「逸出」到臨界區以外，那樣會破壞監視器的語義）。JMM 會在退出臨界區和進入臨界區這兩個關鍵時間點作一些特別處理，使得線程在這兩個時間點具備與順序一致性模型相同的內存視圖。雖然線程 A 在臨界區內作了重排序，但因爲監視器的互斥執行的特性，這裏的線程 B 根本沒法「觀察」到線程 A 在臨界區內的重排序。這種重排序既提升了執行效率，又沒有改變程序的執行結果。
從這裏咱們能夠看到 JMM 在具體實現上的基本方針：在不改變（正確同步的）程序執行結果的前提下，儘量的爲編譯器和處理器的優化打開方便之門。
未同步程序的執行特性
未同步程序在 JMM 中的執行時，總體上是無序的，其執行結果沒法預知。未同步程序在兩個模型中的執行特性有下面幾個差別：
- 順序一致性模型保證單線程內的操做會按程序的順序執行，而 JMM 不保證單線程內的操做會按程序的順序執行（好比上面正確同步的多線程程序在臨界區內的重排序）。
- 順序一致性模型保證全部線程只能看到一致的操做執行順序，而 JMM 不保證全部線程能看到一致的操做執行順序。
- JMM 不保證對 64 位的 long 型和 double 型變量的讀/寫操做具備原子性，而順序一致性模型保證對全部的內存讀/寫操做都具備原子 。
第三個差別與處理器總線的工做機制密切相關。在計算機中，數據經過總線在處理器和內存之間傳遞。每次處理器和內存之間的數據傳遞都是經過總線事務來完成的。總線事務包括讀事務和寫事務。讀事務從內存傳送數據處處理器，寫事務從處理器傳遞數據到內存，每一個事務會讀／寫內存中一個或多個物理上連續的字。總線會同步試圖併發使用總線的事務。在一個處理器執行總線事務期間，總線會禁止其它全部的處理器和 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 特性
舉個例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public
class
VolatileTest {
volatile
long
a = 1L;
// 使用 volatile 聲明 64 位的 long 型
public
void
set(
long
l) {
a = l;
//單個 volatile 變量的寫
}
public
long
get() {
return
a;
//單個 volatile 變量的讀
}
public
void
getAndIncreament() {
a++;
// 複合（多個） volatile 變量的讀 /寫
}
}
|
假設有多個線程分別調用上面程序的三個方法，這個程序在語義上和下面程序等價：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
public
class
VolatileTest {
long
a = 1L;
// 64 位的 long 型普通變量
public
synchronized
void
set(
long
l) {
//對單個普通變量的寫用同一個鎖同步
a = l;
}
public
synchronized
long
get() {
//對單個普通變量的讀用同一個鎖同步
return
a;
}
public
void
getAndIncreament() {
//普通方法調用
long
temp = get();
//調用已同步的讀方法
temp += 1L;
//普通寫操做
set(temp);
//調用已同步的寫方法
}
}
|
如上面示例程序所示，對一個 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 包的源代碼實現，會發現一個通用化的實現模式：
- 首先，聲明共享變量爲 volatile；
- 而後，使用 CAS 的原子條件更新來實現線程之間的同步；
- 同時，配合以 volatile 的讀/寫和 CAS 所具備的 volatile 讀和寫的內存語義來實現線程之間的通訊。
AQS，非阻塞數據結構和原子變量類（java.util.concurrent.atomic 包中的類），這些 concurrent 包中的基礎類都是使用這種模式來實現的，而 concurrent 包中的高層類又是依賴於這些基礎類來實現的。從總體來看，concurrent 包的實現示意圖以下：
final
對於 final 域，編譯器和處理器要遵照兩個重排序規則：
- 在構造函數內對一個 final 域的寫入，與隨後把這個被構造對象的引用賦值給一個引用變量，這兩個操做之間不能重排序。
- 初次讀一個包含 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 中與在順序一致性內存模型中的執行結果的異同：
我有一個微信公衆號，常常會分享一些Java技術相關的乾貨；
若是你喜歡個人分享，能夠用微信搜索「Java團長」或者「javatuanzhang」關注。
轉自：http://www.54tianzhisheng.cn/2018/02/28/Java-Memory-Model/