【轉】深刻理解Java內存模型（七）——總結

處理器內存模型

順序一致性內存模型是一個理論參考模型，JMM和處理器內存模型在設計時一般會把順序一致性內存模型做爲參照。JMM和處理器內存模型在設計時會對順序一致性模型作一些放鬆，由於若是徹底按照順序一致性模型來實現處理器和JMM，那麼不少的處理器和編譯器優化都要被禁止，這對執行性能將會有很大的影響。

根據對不一樣類型讀/寫操做組合的執行順序的放鬆，能夠把常見處理器的內存模型劃分爲下面幾種類型：

1. 放鬆程序中寫-讀操做的順序，由此產生了total store ordering內存模型（簡稱爲TSO）。
2. 在前面1的基礎上，繼續放鬆程序中寫-寫操做的順序，由此產生了partial store order 內存模型（簡稱爲PSO）。
3. 在前面1和2的基礎上，繼續放鬆程序中讀-寫和讀-讀操做的順序，由此產生了relaxed memory order內存模型（簡稱爲RMO）和PowerPC內存模型。

注意，這裏處理器對讀/寫操做的放鬆，是以兩個操做之間不存在數據依賴性爲前提的（由於處理器要遵照as-if-serial語義，處理器不會對存在數據依賴性的兩個內存操做作重排序）。

 

下面的表格展現了常見處理器內存模型的細節特徵：

內存模型名稱	對應的處理器	Store-Load 重排序	Store-Store重排序	Load-Load 和Load-Store重排序	能夠更早讀取到其它處理器的寫	能夠更早讀取到當前處理器的寫
TSO	sparc-TSO X64	Y				Y
PSO	sparc-PSO	Y	Y			Y
RMO	ia64	Y	Y	Y		Y
PowerPC	PowerPC	Y	Y	Y	Y	Y

在這個表格中，咱們能夠看到全部處理器內存模型都容許寫-讀重排序，緣由在第一章以說明過：它們都使用了寫緩存區，寫緩存區可能致使寫-讀操做重排序。同時，咱們能夠看到這些處理器內存模型都容許更早讀到當前處理器的寫，緣由一樣是由於寫緩存區：因爲寫緩存區僅對當前處理器可見，這個特性致使當前處理器能夠比其餘處理器先看到臨時保存在本身的寫緩存區中的寫。

上面表格中的各類處理器內存模型，從上到下，模型由強變弱。越是追求性能的處理器，內存模型設計的會越弱。由於這些處理器但願內存模型對它們的束縛越少越好，這樣它們就能夠作儘量多的優化來提升性能。

因爲常見的處理器內存模型比JMM要弱，java編譯器在生成字節碼時，會在執行指令序列的適當位置插入內存屏障來限制處理器的重排序。同時，因爲各類處理器內存模型的強弱並不相同，爲了在不一樣的處理器平臺向程序員展現一個一致的內存模型，JMM在不一樣的處理器中須要插入的內存屏障的數量和種類也不相同。下圖展現了JMM在不一樣處理器內存模型中須要插入的內存屏障的示意圖：

如上圖所示，JMM屏蔽了不一樣處理器內存模型的差別，它在不一樣的處理器平臺之上爲java程序員呈現了一個一致的內存模型。

JMM，處理器內存模型與順序一致性內存模型之間的關係

JMM是一個語言級的內存模型，處理器內存模型是硬件級的內存模型，順序一致性內存模型是一個理論參考模型。下面是語言內存模型，處理器內存模型和順序一致性內存模型的強弱對比示意圖：

從上圖咱們能夠看出：常見的4種處理器內存模型比經常使用的3中語言內存模型要弱，處理器內存模型和語言內存模型都比順序一致性內存模型要弱。同處理器內存模型同樣，越是追求執行性能的語言，內存模型設計的會越弱。

JMM的設計

從JMM設計者的角度來講，在設計JMM時，須要考慮兩個關鍵因素：

• 程序員對內存模型的使用。程序員但願內存模型易於理解，易於編程。程序員但願基於一個強內存模型來編寫代碼。
• 編譯器和處理器對內存模型的實現。編譯器和處理器但願內存模型對它們的束縛越少越好，這樣它們就能夠作儘量多的優化來提升性能。編譯器和處理器但願實現一個弱內存模型。

因爲這兩個因素互相矛盾，因此JSR-133專家組在設計JMM時的核心目標就是找到一個好的平衡點：一方面要爲程序員提供足夠強的內存可見性保證；另外一方面，對編譯器和處理器的限制要儘量的放鬆。下面讓咱們看看JSR-133是如何實現這一目標的。

爲了具體說明，請看前面提到過的計算圓面積的示例代碼：

double pi  = 3.14;    //A
double r   = 1.0;     //B
double area = pi * r * r; //C

上面計算圓的面積的示例代碼存在三個happens- before關係：

1. A happens- before B；
2. B happens- before C；
3. A happens- before C；

因爲A happens- before B，happens- before的定義會要求：A操做執行的結果要對B可見，且A操做的執行順序排在B操做以前。 可是從程序語義的角度來講，對A和B作重排序即不會改變程序的執行結果，也還能提升程序的執行性能（容許這種重排序減小了對編譯器和處理器優化的束縛）。也就是說，上面這3個happens- before關係中，雖然2和3是必須要的，但1是沒必要要的。所以，JMM把happens- before要求禁止的重排序分爲了下面兩類：

• 會改變程序執行結果的重排序。
• 不會改變程序執行結果的重排序。

JMM對這兩種不一樣性質的重排序，採起了不一樣的策略：

• 對於會改變程序執行結果的重排序，JMM要求編譯器和處理器必須禁止這種重排序。
• 對於不會改變程序執行結果的重排序，JMM對編譯器和處理器不做要求（JMM容許這種重排序）。

下面是JMM的設計示意圖：

從上圖能夠看出兩點：

• JMM向程序員提供的happens- before規則能知足程序員的需求。JMM的happens- before規則不但簡單易懂，並且也向程序員提供了足夠強的內存可見性保證（有些內存可見性保證其實並不必定真實存在，好比上面的A happens- before B）。
• JMM對編譯器和處理器的束縛已經儘量的少。從上面的分析咱們能夠看出，JMM實際上是在遵循一個基本原則：只要不改變程序的執行結果（指的是單線程程序和正確同步的多線程程序），編譯器和處理器怎麼優化都行。好比，若是編譯器通過細緻的分析後，認定一個鎖只會被單個線程訪問，那麼這個鎖能夠被消除。再好比，若是編譯器通過細緻的分析後，認定一個volatile變量僅僅只會被單個線程訪問，那麼編譯器能夠把這個volatile變量看成一個普通變量來對待。這些優化既不會改變程序的執行結果，又能提升程序的執行效率。

JMM的內存可見性保證

Java程序的內存可見性保證按程序類型能夠分爲下列三類：

1. 單線程程序。單線程程序不會出現內存可見性問題。編譯器，runtime和處理器會共同確保單線程程序的執行結果與該程序在順序一致性模型中的執行結果相同。
2. 正確同步的多線程程序。正確同步的多線程程序的執行將具備順序一致性（程序的執行結果與該程序在順序一致性內存模型中的執行結果相同）。這是JMM關注的重點，JMM經過限制編譯器和處理器的重排序來爲程序員提供內存可見性保證。
3. 未同步/未正確同步的多線程程序。JMM爲它們提供了最小安全性保障：線程執行時讀取到的值，要麼是以前某個線程寫入的值，要麼是默認值（0，null，false）。

下圖展現了這三類程序在JMM中與在順序一致性內存模型中的執行結果的異同：

只要多線程程序是正確同步的，JMM保證該程序在任意的處理器平臺上的執行結果，與該程序在順序一致性內存模型中的執行結果一致。

JSR-133對舊內存模型的修補

JSR-133對JDK5以前的舊內存模型的修補主要有兩個：

• 加強volatile的內存語義。舊內存模型容許volatile變量與普通變量重排序。JSR-133嚴格限制volatile變量與普通變量的重排序，使volatile的寫-讀和鎖的釋放-獲取具備相同的內存語義。
• 加強final的內存語義。在舊內存模型中，屢次讀取同一個final變量的值可能會不相同。爲此，JSR-133爲final增長了兩個重排序規則。如今，final具備了初始化安全性。

轉自：http://www.infoq.com/cn/articles/java-memory-model-7