在并發編程中，線程之間的通信是一個很關鍵的問題，而該問題解決方案主要可分為兩大類：消息傳遞、共享內存。前者有以Erlang語言為代表的Actor模型，而后者中典型的則是Java語言。對于消息傳遞機制而言，線程之間必須通過發送消息以進行顯式地通信。而同步過程則是隱式地，因為消息的發送必須在消息的接收之前；而對于共享內存機制來說，線程之間可以通過讀、寫內存中的公共狀態來實現隱式地通信，但同步操作則需通過開發者顯式地進行指定。可以看到由于Java的并發采用是共享內存機制，所以在談多線程并發編程之前，需要對JMM(Java Memory Model)Java內存模型有一定的了解
CPU內存模型與緩存一致性問題
CPU內存模型
在談論Java內存模型之前，我們先來了解下現代CPU內存模型。下面是一個雙核CPU的組成示意圖，每個CPU都包含一個獨有的一級緩存，同時還有一個可被所有CPU共享的二級緩存。多級Cache的作用就是為了緩沖現代CPU與主內存Ram之間嚴重不匹配的速度
Cache Coherency 緩存一致性問題
雙核甚至多核CPU的出現，使得多個線程可以在不同的CPU中執行，可以大大減少單核CPU由于頻繁切換線程而引起的上下文切換開銷。目前看來好像一切都是美妙的。但是很快人們發現，這會引發一個新的問題——Cache Coherency 緩存一致性問題。
假設現在我們有兩個線程A、B分別使用CPU #1、#2執行，其中在主內存Ram有一個共享變量a，其初始值為1
- Step 1 : 線程A將變量a的值修改為2
線程A首先獲取共享變量a值，由于兩級緩存L1 Cache、L2 Cache均未命中，故只能從主內存Ram中加載；然后將a=1緩存到兩級緩存中；最后線程A修改了變量a的值為2，并將其寫入兩級緩存、主內存中
figure 2.jpeg
- Step 2 : 線程B對變量a進行自增
線程B首先獲取共享變量a值，二級緩存L2 Cache被命中，其值為2；然后對變量a自增變為3，并將其寫入兩級緩存、主內存中
figure 3.jpeg
目前為止一切都是正常的，經過Step1、2兩步操作后，主內存中變量a的值變為3，符合我們的預期
- Step 3 : 線程A對變量a進行自增
線程A首先獲取共享變量a值，一級緩存L1 Cache被命中，其值為2；然后對變量a自增變為3，并將其寫入兩級緩存、主內存中
figure 4.jpeg
等等，好像哪里不對啊！在Step2后共享變量在主內存中已經是3了，那么Step3中線程A如果再次對其自增后，主內存中的變量a的值應該更新為4才對啊。但實際上執行完Step3后，主內存變量a的卻依然是3
相信聰明的朋友可能已經看出來原因所在了，在Step2后，雖然主內存中變量a的值已經更新為3了，但是在CPU #1獨有的L1 Cache中，變量a的值卻還是2未被更新。換言之，由于各CPU內部Cache之間的不可見性，CPU無法感知到其他CPU Cache對數據所做的更新、修改，從而引發 Cache Coherency 緩存一致性問題
總線加鎖
為了解決Cache Coherency 緩存一致性問題，早期是通過直接對主內存與共享Cache(即這里的L2 Cache)之間的總線加鎖來解決的。在我們上面的例子中，線程A的工作就是將變量a修改為2，然后再對其自增；而B線程的工作是將變量a的值自增一次。現在假設依然是Step 1先執行，即線程A將主存中變量a的值修改為2了。由于總線加鎖機制的存在，在線程A第一次從主存中加載值為1的變量a時，總線即會主存中變量a進行加鎖，使得其他CPU(即這里的CPU #2的線程B)無法讀、寫該變量只等進行等待，直到線程A完成了對該變量的全部操作Step1、Step3——即先將變量a修改為2，再自增為3。當線程A將變量a的值3最終寫入主內存后，總線才會將該鎖釋放。此時線程B才可以從主內存中加載變量a執行自增操作，并最終將a=4寫入到主內存中(當然總線在此期間同樣會再次對總線進行加鎖，以保證CPU #2的線程B對其進行獨占)。即在總線加鎖的機制下，如果線程A先拿到總線鎖，則線程A、B的任務執行順序是Step1、Step3、Step2。雖然通過總線加鎖的方式可以解決我們上面提到的緩存一致性問題，但是弊端同樣顯而易見，總線加鎖會導致其他線程完全無法操作該變量，只能進行等待。換句話說，總線加鎖的效率太低、開銷太大，嚴重浪費了多核CPU的性能
MESI協議-緩存鎖
為了解決總線加鎖的弊端，現代CPU在訪問Cache的過程中，可通過遵循一些協議來解決緩存一致性問題。典型地有Intel的MESI緩存一致性協議。在MESI協議中，當多個CPU從主內存加載同一個共享變量的數據并緩存到各自Cache后，一旦某個CPU修改了該變量在其緩存中的數據后，立刻將修改后的數據同步到主內存中。通過對Cache中該數據所在的緩存行加鎖來阻止其他CPU同時修改主內存中該變量的數據，當主內存數據被修改完畢后即釋放鎖。與此同時，其他CPU可通過總線嗅探機制感知到該變量的數據變化從而將自己CPU內部相應的緩存數據失效。可以看到，MESI協議，一方面讓CPU可以感知其他CPU中緩存數據的修改、變化來及時將自己Cache中的數據失效；另一方面只對緩存數據在回寫到主內存的過程進行加鎖，即使用緩存鎖的方式，大大減小了鎖的粒度，提高了多核CPU的利用率
Java Memory Model
有了前面CPU內存模型的引子，現在讓我們回到正題來了解下什么是Java Memory Model(Java內存模型)。Java試圖定義一種內存模型，其能夠屏蔽各種硬件底層、操作系統的內存訪問差異，以保證Java程序在各種平臺下的一致的內存訪問效果。而在JDK 1.5版本中通過實現JSR-133，Java內存模型才被真正地完善地成熟地建立起來了。所以本文所談論的Java內存模型均是基于JSR-133而言的
Java內存模型規定共享變量存儲在主內存中，當Java線程使用該共享變量時，需要先將其拷貝到該線程所屬的工作內存中。換句話說，線程對共享變量的操作只能在該線程的工作內存中進行，而不能直接讀寫主內存中的變量。當然線程之間也無法直接訪問對方工作內存中的變量，所以線程之間共享變量值的傳遞均需通過主內存來完成。其示意圖如下所示，可以看到JMM在設計上與我們之前介紹的CPU內存模型有很大相似之處
figure 5.jpeg
上面所說的共享變量，具體則是指實例變量、靜態變量以及數組中的元素，但不包括局部變量、方法參數。因為后者(局部變量、方法參數)是線程私有的，自然不會被共享。需要注意的是，Java內存模型只是是一個抽象的概念，其中主內存一般對應于計算機硬件的Ram，而工作內存則不真實存在，其可能會對應于CPU寄存器、緩存或Ram。同時這里希望大家不要將JMM中的主內存、工作內存與JVM Java虛擬機中的堆、棧、方法區等Java內存區域相混淆，因為二者不是在一個層次上的內存劃分，這里JMM是為Java并發而服務的
并發編程的三個特性
Java內存模型就是圍繞著在并發過程中如何處理原子性、可見性、有序性這三個特性來建立的，其通過相關的規范、規則來避免并發編程可能出現的線程安全問題
Atomicity 原子性
原子性是指一個或多個操作是不可中斷的，要么全部執行，要么全部不執行，不存在只執行其中一部分的情況。在JMM中定義了以下八種操作來完成共享變量在主內存與工作內存之間的具體交互。與此同時，下面提及的每一種操作均由JMM來直接保證其具備原子性，所以Java虛擬機實現時必須要滿足下列操作的原子性
- lock(鎖定) ：作用于主內存的變量，它把一個變量標示為一條線程獨占的狀態
- unlock(解鎖) ：作用于主內存的變量，它把一個處于鎖定狀態的變量釋放出來，釋放后的變量才可以被其他線程鎖定
- read(讀取) ：作用于主內存的變量，它把一個變量的值從主內存傳輸到線程內的工作內存中，以便隨后的load操作使用
- load(載入) ：作用于工作內存的變量，它把read操作從主內存中得到的變量值放入工作內存的變量副本中
- use(使用) ：作用于工作內存的變量，它把工作內存中一個變量的值傳遞給執行引擎，每當虛擬機遇到一個需要使用到變量的值的字節碼指令時將會執行此操作
- assign(賦值) ：作用于工作內存的變量，它把一個從執行引擎接收到的值賦給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行此操作
- store(存儲) ：作用于工作內存的變量，它把工作內存中一個變量的值傳遞到主內存中，以便隨后的write操作使用
- write(寫入) ：作用于主內存的變量，它把store操作從工作內存中得到的變量值放入主內存的變量中
在開發中通常需要保證多個操作的原子性，所以在JMM中提供了lock、unlock操作，盡管虛擬機未將這兩個操作開放提供給用戶使用。但是卻提供了更高層次的字節碼指令monitorenter、monitorexit來隱式地使用了這兩個操作，而這兩個字節碼指令反映到Java代碼層面就是同步塊——synchronized關鍵字。所以synchronized塊之間的一系列操作同樣具備原子性
Note
值得一提的是，對于long、double類型變量而言，JMM并不強制要求虛擬機在實現時保證read、load、store、write操作的原子性，即所謂的long、double的非原子性協定。不過就實際開發而言，我們也無需過多擔心這點。因為目前大多數商用虛擬機幾乎都會選擇實現long、double數據讀寫操作的原子性
Visibility 可見性
可見性則是當一個線程修改了共享變量的值，其他線程能夠立即感知到這個修改。前面我們已經提到JMM中各線程的工作內存相互是不可見的，即不可以直接訪問其他線程的工作內存。所以在JMM中可見性是通過主內存作為傳遞媒介來實現的，即線程在修改了共享變量的值后需要同步回主內存，在線程讀取時從主內存拷貝副本
Ordering 有序性
重排序
一般大家會認為程序的執行是按我們程序編碼時的順序關系順序執行，但實際上并不是這樣。現代CPU會利用一些諸如多級流水線(多條指令可重疊執行)等并行技術來提高執行效率。CPU可以將多條指令打亂來重新組織執行順序，而不按程序編碼時的順序進行執行，即CPU的亂序執行(out-of-order execution，OOE)。與此同時，編譯器在很多情況下(例如優化等)也會對指令執行順序進行調整。基于此，不論是編譯器還是處理器CPU都會對程序指令進行重排序。通過下面這個示例即可觀察到重排序這一現象
public?class?Ordering?{
????public?static?int?x?=?0;
????public?static?int?y?=?0;
????public?static?void?test1()?throws?Exception?{
????????HashSet?resultSet?=?new?HashSet<>();for(?long?i=0;?i500000*100);?i++?)?{
????????????x?=?0;
????????????y?=?0;
????????????Map?map?=?new?ConcurrentHashMap<>();
????????????Thread?threadA?=?new?Thread(()?->
????????????{int?a?=?y;??//?①
????????????????x?=?1;??????//?②
????????????????map.put("a",?a);
????????????});
????????????Thread?threadB?=?new?Thread(()?->
????????????{int?b?=?x;???//?③
????????????????y?=?1;??????//?④
????????????????map.put("b",?b);
????????????});
????????????threadA.start();
????????????threadB.start();
????????????threadA.join();
????????????threadB.join();
????????????String?result?=?"?{?a="?+?map.get("a")?+?",?b="?+?map.get("b")?+?"?}?";
????????????resultSet.add(result);
????????}
????????System.out.println(resultSet);
????}
}從下面執行結果中紅框部分，我們可以看到竟然出現a=1,b=1的執行結果，其可以說明在程序的執行順序中 ②比③先執行、④比①先執行。而要滿足上述的執行順序，要么是因為②比①先執行，要么是因為④比③先執行。即程序指令發生了重排序
figure 6.png
As-If Serial 語義
As-If Serial 語義，是指無論做怎樣的重排序單線程的執行結果都不應被改變。即在本線程內進行觀察，程序的執行是有序的而沒有亂序執行，看上去是串行的。考慮下面的例子，下面3行代碼的順序是 ①->②->③，但是由于①與②之間不存在任何數據依賴關系，所以編譯器、處理器可以對①、②操作進行重排序。即實際的執行順序可能是 ②->①->③，雖然對指令進行了重排序，但并不影響最終的結果
double?pi?=?3.14159;???//?①
double?r?=?2.0;?????//?②
double?s?=?pi?*?r?*?r;??//?③
所以說，遵守As-If Serial語義的編譯器、Runtime和硬件(CPU等)共同把單線程程序保護了起來，即在程序中不應能夠觀察到重排序的效果。其為開發單線程程序的開發者創建了一個幻覺，即單線程程序是按程序編碼的順序來執行的。Java內存模型在單線程中的有序性可由As-If Serial語義提供保證
Happens-Before 先行發生原則
在Java的多線程程序中，如果在一個線程中觀察另外一個線程，則可以發現其所有的操作都是無序的。其原因在于指令的重排序、工作內存與主內存同步延遲。為此Java提供了volatile、synchronized兩個關鍵字來保證線程間操作的有序性。而如果在Java內存模型中所有的有序性都僅僅依靠volatile、synchronized來實現的話，那么就會導致我們在實際開發多線程程序時非常繁瑣。為此Java內存模型中提出了一個 Happens-Before 先行發生原則，其定義了兩項操作之間的偏序關系。當A操作先行發生于操作B，其含義是在發生B操作之前，A操作產生的影響(包括但不限于修改共享變量的值、發送消息、調用方法)能夠被B操作觀察到
程序順序規則 ：在一個線程內，按照分支、循環等控制流等順序，編寫在前面的操作先行發生于書寫在后面的操作 監視器鎖規則 ：一個unlock操作先行發生于后面對同一個鎖的lock操作。這里的后面是指令在執行時間上的先后順序 volatile變量規則 ：對一個volatile變量的寫操作先行發生于后面對這個變量的讀操作。這里的后面是指令在執行時間上的先后順序 線程啟動規則 ：Thread對象的start()方法先行發生于此線程的每一個動作 線程終止規則 ：線程中的所有操作都先行發生于對此線程的終止檢測，我們可以通過Thread.join()方法結束、Thread.isAlive()的返回值等手段檢測到線程已經終止執行 線程中斷規則 ：對線程interrupted()方法的調用先行發生于被中斷線程的代碼檢測到中斷事件的發生，可以通過Thread.interrupted()方法檢測到是否有中斷發生 對象終結規則 ：一個對象的初始化完成(構造函數執行結束)先行發生于它的finalize()方法的開始 傳遞性 ：如果操作A先行發生于操作B、操作B先行發生于操作C，那么可以得出操作A先行發生于操作C的結論
在JMM中，這些原則無需任何其他同步手段協助就已經存在。故在實際的開發過程中，Happens-Before 先行發生原則是我們判斷數據競爭、線程安全的主要依據，可以在編碼中直接應用。如果兩個操作之間的關系不在上述原則之列且無法從上述原則中推導出來，那么就無法保證他們的執行順序，即發生重排序
當然值得一提的是，Happens-Before原則實際上是對Java內存模型的一種近似性描述，不夠嚴謹，但是可以方便我們日常開發應用參考。例如在一個線程中存在如下代碼
double?pi?=?3.14159;???//?①
double?r?=?2.0;?????//?②
double?s?=?pi?*?r?*?r;??//?③
根據程序順序原則，我們可以得到下面的三個偏序關系：
- ①先行于③發生
- ②先行于③發生
- ①先行于②發生
前2個偏序關系顯然是必要的，但是對于第3個偏序關系則不是必要的。也就是說①、②發生重排序，②先行于①發生，并不會改變程序的執行結果。故如果Happens-Before所禁止的重排序并不會改變程序的執行結果，JMM將不會要求編譯器、處理器來禁止該重排序。即在此種條件下JMM允許進行重排序。這樣做的目的也是顯然易見的，即最大程度減少對編譯器、處理器優化的限制
Memory Barrier 內存屏障
JMM向上給開發者提供了一些規則來保證并發編程時的一定有序性，向下則是通過編譯器在適當位置插入相關Memory Barrier 內存屏障指令禁止特定類型的重排序來實現相關操作的有序。Memory Barrier 內存屏障，又稱作Memory Fence內存柵欄，其是對一類CPU指令的統稱。其作用在于保證CPU執行相關操作時一定的有序，避免CPU對相關指令的亂序執行。具體的，JMM將內存屏障指令分為以下四種類型
- LoadLoad屏障 ：在指令序列 Load1; LoadLoad; Load2 中，該類型屏障確保Load1數據的裝載先于Load2及其后所有裝載指令的的操作
- StoreStore屏障 ：在指令序列 Store1; StoreStore; Store2 中，該類型屏障確保Store1數據的內存寫入(使其對其他處理器可見)先于Store2及其后所有存儲指令的操作
- LoadStore屏障 ：在指令序列 Load1; LoadStore; Store2 中，該類型屏障確保Load1數據的裝載先于Store2及其后所有存儲指令的操作
- StoreLoad屏障 ：在指令序列 Store1; StoreLoad; Load2 中，該類型屏障確保Store1數據的內存寫入(使其對其他處理器可見)先于Load2及其后所有裝載指令的操作。在大多數處理器的實現中該類型屏障由于同時具備其他三個類型屏障的效果，所以其是一個萬能屏障。當然該屏障開銷也是最大的
參考文獻
- Java并發編程之美 翟陸續、薛賓田著
- 深入理解Java虛擬機·第2版 周志明著
- JSR-133: Java Memory Model and Thread Specification
)
