我對Java內存模型的理解
所有的編程語言中都有內存模型這個概念，區別于微架構的內存模型，高級語言的內存模型包括了編譯器和微架構兩部分。我試圖了解了Java、C#和Go語言的內存模型，發現內容基本大同小異，只是這些語言在具體實現的時候略有不同。
我們來看看Java內存模型吧，提到Java內存模型大家對這個圖一定非常熟悉：
這張圖告訴我們在線程運行的時候有一個內存專用的一小塊內存，當Java程序會將變量同步到線程所在的內存，這時候會操作工作內存中的變量，而線程 中變量的值何時同步回主內存是不可預期的。但同時Java內存模型又告訴我們通過使用關鍵詞“synchronized”或“volatile”可以讓 Java保證某些約束：
“volatile” — 保證讀寫的都是主內存的變量
“synchronized” — 保證在塊開始時都同步主內存的值到工作內存，而塊結束時將變量同步回主內存
通過以上描述我們就可以寫出線程安全的Java程序，JDK也同時幫我們屏蔽了很多底層的東西。
但當你深入了解JVM的時候你會發現根本就沒有工作內存這個東西，即內存中根本不會分配這么一塊空間來運行你的Java程序，那么工作內存到底是什么東西呢？
這個問題也曾經困擾了我很長時間，因為我從來沒有從JVM的實現中找到過和主內存同步的代碼，因為當使用“volatile”時我僅僅能從源代碼中調用了這行語句：
- __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
而這個指令在部分微架構上的主要功能就是防止指令重排，即這條指令前后的其它指令不會越過這個界限執行[注1]。
在現在的x86/x64微架構中讀寫內存的一致性都是通過MESI（Intel使用MESI-F，AMD使用MOESI）協議保證[注2]，MESI的狀態轉換圖如下：
更詳細的中文文檔描述可以查看這個文檔：http://blog.csdn.net/zhuliting/article/details/6210921
那Java內存模型中所說的工作內存是什么呢？
我的理解是，首先“工作內存”是一個虛擬的概念，而承載這個概念主要是兩部分：
1. 編譯器
2. 微架構
作為編譯器肯定是執行速度越快越好，所以作為編譯器應當盡量減少從內存讀數據，如果一個數據在寄存器中，那么直接使用寄存器中的值無疑性能是*** 的，但同時這也會導致可能讀不到***的值，這里我們通過在Java語言中為變量加上“volatile”強制告訴編譯器這個變量一定要從內存獲得，這時編 譯器即不會做此類優化【案例見參考資料5（是一個.Net的例子）】。
對于微架構來說，在x86/x64下，CPU會在執行指令時做指令重排，即編譯器生成的指令順序和真正在CPU執行的順序可能是不一致的。當我們用一個變量做信號的時候這種指令重排會帶來悲劇，即如果有如下代碼：
- x = 0;
- y = 0;
- i = 0;
- j = 0;
- // thread A
- y = 1;
- x = 1;
- // thread B
- i = x;
- j = y;
上面的代碼i和j的值會是多少呢？答案是：“00， 01， 10， 11”都是有可能的。
對于這種情況，如果我們想得到確定的結果則需要通過“synchronized”（或者j.c.u.locks）來做線程間同步。
所以，我個人對Java內存模型的理解是：在編譯器各種優化及多種類型的微架構平臺上，Java語言規范制定者試圖創建一個虛擬的概念并傳遞到 Java程序員，讓他們能夠在這個虛擬的概念上寫出線程安全的程序來，而編譯器實現者會根據Java語言規范中的各種約束在不同的平臺上達到Java程序 員所需要的線程安全這個目的。
注1：關于“lock”前綴的詳細說明可以查看這個文檔《Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: System Programming Guide, Part 1》的 這個章節“CHAPTER 8 MULTIPLE-PROCESSOR MANAGEMENT”。
注2：不同的微架構的內存模型都會有一些差別，本文中都是指x86/x64，如果想了解更多的微架構是如何處理的可以參考這個文檔：http://gee.cs.oswego.edu/dl/jmm/cookbook.html
原文鏈接：http://ifeve.com/talk-to-my-understanding-of-the-java-memory-model/
