程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> 深入理解Java內存模型(七) 總結

深入理解Java內存模型(七) 總結

編輯:關於JAVA

處理器內存模型

順序一致性內存模型是一個理論參考模型,JMM和處理器內存模型在設計時通 常會把順序一致性內存模型作為參照。JMM和處理器內存模型在設計時會對順序一致性模型做一些放松, 因為如果完全按照順序一致性模型來實現處理器和JMM,那麼很多的處理器和編譯器優化都要被禁止,這 對執行性能將會有很大的影響。

根據對不同類型讀/寫操作組合的執行順序的放松,可以把常見處 理器的內存模型劃分為下面幾種類型:

放松程序中寫-讀操作的順序,由此產生了total store ordering內存模型(簡稱為TSO)。

在前面1的基礎上,繼續放松程序中寫-寫操作的順序,由此產生了partial store order 內存模型( 簡稱為PSO)。

在前面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關系:

A  happens- before B;

B  happens- before C;

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程序的內存可見性保證按程序類型可以分為下列三類:

單線程程序。單線程程序不會出現內存可見性問題。編譯器,runtime和處理器會共同確保單線程程序 的執行結果與該程序在順序一致性模型中的執行結果相同。

正確同步的多線程程序。正確同步的多線程程序的執行將具有順序一致性(程序的執行結果與該程序 在順序一致性內存模型中的執行結果相同)。這是JMM關注的重點,JMM通過限制編譯器和處理器的重排序 來為程序員提供內存可見性保證。

未同步/未正確同步的多線程程序。JMM為它們提供了最小安全性保障:線程執行時讀取到的值,要麼 是之前某個線程寫入的值,要麼是默認值(0,null,false)。

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

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

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

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

增強volatile的內存語義。舊內存模型允許volatile變量與普通變量重排序。JSR-133嚴格限制 volatile變量與普通變量的重排序,使volatile的寫-讀和鎖的釋放-獲取具有相同的內存語義。

增強final的內存語義。在舊內存模型中,多次讀取同一個final變量的值可能會不相同。為此,JSR- 133為final增加了兩個重排序規則。現在,final具有了初始化安全性。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved