出自 > [深入理解Java內存模型（七）——總結](http://www.infoq.com/cn/articles/java-memory-model-7) [TOC=1,2] ## 處理器內存模型 順序一致性內存模型是一個理論參考模型，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-TSOX64 | 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具有了初始化安全性。 ## 參考文獻 1. [Computer Architecture: A Quantitative Approach, 4th Edition](http://www.amazon.com/Computer-Architecture-Fourth-Quantitative-Approach/dp/0123704901/ref=sr_1_10/102-0116773-7214567?ie=UTF8&s=books&qid=1188797467&sr=1-10) 2. [Shared memory consistency models: A tutorial](http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf) 3. [Intel? Itanium? Architecture Software Developer’s Manual Volume 2: System Architecture](http://www.intel.com/content/dam/www/public/us/en/documents/manuals/itanium-architecture-software-developer-rev-2-3-vol-2-manual.pdf) 4. [Concurrent Programming on Windows](http://www.amazon.com/Concurrent-Programming-Windows-Joe-Duffy/dp/032143482X/ref=sr_1_1?ie=UTF8&s=books&qid=1262571776&sr=1-1) 5. [JSR 133 (Java Memory Model) FAQ](http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html) 6. [The JSR-133 Cookbook for Compiler Writers](http://gee.cs.oswego.edu/dl/jmm/cookbook.html) 7. [Java theory and practice: Fixing the Java Memory Model, Part 2](http://www.ibm.com/developerworks/java/library/j-jtp03304/index.html) ## 關于作者 程曉明，Java軟件工程師，國家認證的系統分析師、信息項目管理師。專注于并發編程，就職于富士通南大。個人郵箱：[asst2003@163.com](mailto:asst2003@163.com)。