概述
衡量一個服務性能的高低好壞，每秒事務處理數（Transactions Per Second，TPS） 是最重要的指標之一，它代表著一秒內服務器平均能響應的請求總數，而TPS值與程序的並發能力又有非常密切的關系。
Java內存模型（Java Memory Model，JMM）用來屏蔽掉各種硬件和操作系統的內存訪問差異，以實現讓Java程序在各種平台下都能達到一致的內存訪問效果。Java內存模型的主要目標是定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣的底層細節。
C/C++：直接使用了物理硬件和操作系統的內存模型。
硬件的效率與一致性
絕大多數的運算任務都不可能只靠處理器“計算”就能完成，處理器至少要與內存交互，如讀取運算速度、存儲運算結果等，這個I/O操作是很難消除的（無法僅靠寄存器來完成所有運算任務）。由於計算機的存儲設備（慢）與處理器的運算速度（快）有幾個數量級的差距，所以現代計算機系統都不得不加入一層讀寫速度盡可能接近處理器運算速度的高速緩存（Cache）來作為內存與處理器之間的緩沖：將運算需要使用到的數據復制到緩存中，讓運算能快速進行，當運算結束後再從緩存同步回內存之中，這樣處理器就無須等待緩慢的內存讀寫了。
緩存一致性（Cache Coherence）：在多處理器系統中，每個處理器都有自己的高速緩存，而它們又共享同一主內存（Main Memory），當多個處理器的運算任務都涉及同一塊主內存區域時，將可能導致各自的緩存數據不一致，如果真的發生這種情況，那同步回到主內存時以誰的緩存數據為准呢？為了解決一致性問題，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操作，這類協議有MSI、MESI（illinois Protocol） 、MOSI、Synapse、Firefly及Dragon Protocol等。“內存模型”一詞，可以理解為在特定的操作協議下，對特定的內存或高速緩存進行讀寫訪問的過程抽象。
處理器、高速緩存、主內存間的交互關系：
除了增加高速緩存之外，為了使得處理器內部的運算單元能盡量被充分利用，處理器可能會對輸入代碼進行亂序執行（Out-Of-Order Execution）優化，處理器會在計算之後將亂序執行的結果重組，保證該結果與順序執行的結果是一致的，但並不保證程序中各個語句計算的先後順序與輸入代碼中的順序一致，因此，如果存在一個計算任務依賴另外一個計算任務的之間結果，那麼其順序性並不能靠代碼的先後順序來保證。與處理器的亂序執行優化類似，Java虛擬機的即時編譯器中也有類似的指令重排序（Instruction Reorder）優化。
主內存與工作內存
Java內存模型的主要目標是定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣的底層細節。此處的變量（Variables）包括了實例字段、靜態字段和構造數組對象的元素，但不包括局部變量與方法參數，因為後者是線程私有的，不會被共享，自然就不會存在競爭問題。
Java內存模型規定了所有的變量都存儲在主內存（Main Memory）中，每條線程還有自己的工作內存（Working Memory），線程的工作內存中保存了被該線程使用到的變量的主內存副本拷貝，線程對變量的所有操作（讀取、賦值等）都必須在工作內存中進行，而不能直接讀寫主內存中的變量。不同的線程之間也無法直接訪問對方工作內存中的變量，線程間變量值的傳遞均需要通過主內存來完成。
這裡講的主內存、工作內存與Java內存區域中的Java堆、棧、方法區等不是同一個層次的內存劃分，這兩者基本上沒有關系，如果一定要勉強對應起來：主內存對應於堆，工作內存對應於棧。從更低層次上說，主內存就直接對應於物理硬件的內存，而為了獲得更好的運行速度，虛擬機（甚至是硬件系統本身的優化措施）可能會讓工作內存優先存儲於寄存器和高速緩存中，因為程序運行時主要訪問讀寫的是工作內存。
線程、主內存、工作內存三者之間的交互關系：
內存間交互操作
1）lock（鎖定）：作用於主內存的變量，它把一個變量標識為一條線程獨占的狀態。
2）unlock（解鎖）：作用於主內存的變量，它把一個處於鎖定狀態的變量釋放出來，釋放後的變量才可以被其它線程鎖定。
3）read（讀取）：作用於主內存的變量，它把一個變量的值從主內存傳輸到線程的工作內存中，以便隨後的load動作使用。
4）load（載入）：作用於工作內存的變量，它把read操作從主內存中得到的變量值放入工作內存的變量副本中。
5）use（使用）：作用於工作內存的變量，它把工作內存中一個變量的值傳遞給執行引擎，每當虛擬機遇到一個需要使用到變量的值的字節碼指令時將會執行這個操作。
6）assign（賦值）：作用於工作內存的變量，它把一個從執行引擎接收到的值賦給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行這個操作。
7）store（存儲）：作用於工作內存的變量，它把工作內存中一個變量的值傳送給主內存中，以便隨後的write操作使用。
8）write（寫入）：作用於主內存的變量，它把store操作從工作內存中得到的變量的值放入主內存的變量中。
如果要把一個變量從主內存復制到工作內存，那就要順序執行read和load操作，如果要把一個變量從工作內存同步回主內存，就就要順序地執行store和write操作。注意：Java內存模型只要求上述兩個操作必須按順序執行，而沒有保證是連續執行。除此之外，還必須滿足：
1）不允許read和load、store和write操作之一單獨出現，即不允許一個變量從主內存讀取了但工作內存不接受，或者從工作內存發起回寫了但主內存不接受的情況出現。
2）不允許一個線程丟棄它的最近的assign操作，即變量在工作內存中改變了之後必須把該變化同步回主內存。
3）不允許一個線程無原因地（沒有發生過任何assign操作）把數據從線程的工作內存同步回主內存中。
4）一個新的變量只能在主內存中“誕生”，不允許在工作內存中直接使用一個未被初始化（load或assign）的變量，換句話說，就是對一個變量實施use、store操作之前，必須先執行過了assign和load操作。
5）一個變量在同一時刻只允許一條線程對其進行lock操作，但lock操作可以被同一條線程重復執行多次，多次執行lock後，只有執行相同次數的unlock操作，變量才會被解鎖。
6）如果對一個變量執行了lock操作，那將會清空工作內存中此變量的值，在執行引擎使用這個變量前， 需要重新執行load或assign操作初始化變量的值。
7）如果一個變量事先沒有被lock操作鎖定，那就不允許對它執行unlock操作，也不允許去unlock一個被其它線程鎖定住的變量。
8）對一個變量執行unlock操作之前，必須把此變量同步回主內存中（執行store、write操作）。
對於volatile型變量的特殊規則
當一個變量定義為volatile之後，它將具備兩種特性：
1）保證此變量對所有線程的可見性；普通變量（沒被volatile修飾）做不到這一點，普通變量的值在線程間傳遞均需要通過主內存來完成。
2）volatile變量不是線程安全的；volatile變量在各個線程的工作內存中不存在一致性問題（在各個線程的工作內存中，volatile變量也可以存在不一致的情況，但由於每次使用之前都要先刷新，執行引擎看不到不一致的情況，因此可以認為不存在一致性問題），但是Java裡面的運算並非原子操作，導致volatile變量的運算在並發下一樣是不安全的。
例如：public static volatile int race = 0; race++時，多線程執行會不安全：當getstatic指令把race的值取到操作棧頂時，volatile關鍵字保證了race的值在此時是正確的，但是在執行iconst_1、iadd這些指令的時候，其它線程可能已經把race的值加大了，而在操作棧頂的值就變成了過期的數據，所以putstatic指令執行後就可能把較小的race值同步回主內存之中。
即使編譯出來只有一條字節碼指令，也並不意味執行這條指令就是一個原子操作。
一條字節碼指令在解釋執行時，解釋器將要運行許多行代碼才能實現它的語義，如果是編譯執行，一條字節碼指令也可能轉化成若干條本機機器碼指令。使用-XX:+PrintAssembly參數輸出反匯編來分析更嚴謹。
由於volatile變量只能保證可見性，在不符合以下兩條規則的運算場景中，需要通過加鎖（Synchronized或java.util.concurrent中的原子類）來保證原子性：
1）運算結果並不依賴變量的當前值，或者能夠確保只有單一的線程修改變量的值
2）變量不需要與其它的狀態變量共同參與不變約束
使用Volatile變量的第二個語義是禁止指令重排序優化，普通的變量僅僅會保證在該方法的執行過程中所有依賴賦值結果的地方都能獲取到正確的結果，而不能保證變量賦值操作的順序與程序代碼中的執行順序一致。因為在一個線程的方法執行過程中無法感知到這點，這也就是Java內存模型中描述的所謂的“線程內表現為串行的語義”（Within-Thread As-If-Serial Semantics）。
指令重排序問題。
在某些情況下，volatile的同步機制的性能確實要優於鎖（使用Synchronized關鍵字或java.util.concurrent包裡面的鎖），但是由於虛擬機對鎖實行的許多消除和優化，使得我們很難量化地認為volatile就會比Synchronized快多少。如果讓volatile自己與自己比較，那可以確定一個原則：volatile變量讀操作的性能消耗與普通變量幾乎沒有差別，但是寫操作則可能會慢一些，因為它需要在本地代碼中插入許多內存屏障指令來保證處理器不發生亂序執行。不過即便如此，大多數場景下volatile的總開銷仍然要比鎖低，我們在volatile與鎖之中選擇的唯一依據僅僅是volatile的語義能否滿足使用場景的需求。
假如T表示一個線程，V和W分別表示兩個volatile型變量，那麼在進行read、load、use���assign、store和write操作時需要滿足如下規則：
1）只有當線程T對變量V執行的前一個動作是load的時候，線程T才能對變量V執行use動作；並且，只有當線程T對變量V執行的後一個動作是use的時候，線程T才能對變量V執行load動作。線程T對變量V的use動作可以認為是和線程T對變量V的load、read動作相關聯，必須連續一起出現（這條規則要求在工作內存中，每次使用V前都必須先從主內存刷新最新的值，用於保證能看見其它線程對變量V所做的修改後的值）。
2）只有當線程T對變量V執行的前一個動作是assign的時候，線程T才能對變量V執行store動作；並且，只有當線程T對變量V執行的後一個動作是store的時候，線程T才能對變量V執行assign動作。線程T對變量V的assign動作可以認為是和線程T對變量V的store、write動作相關聯，必須連續一起出現（這條規則要求在工作內存中，每次修改V後都必須立刻同步回主內存中，用於保證其它線程可以看到自己對變量V所做的修改）。
3）假定動作A是線程T對變量V實施的use或assign動作，假定動作F是和動作A相關聯的load或store動作，假定動作P是和動作F相應的對變量V的read或write動作；類似的， 假定動作B是線程T對變量W實施的use或assign動作，假定動作G是和動作B相關聯的load或store動作，假定動作Q是和動作G相應的對變量W的read或write動作。如果A先於B，那麼P先於Q（這條規則要求volatile修飾的變量不會被指令重排序優化，保證代碼的執行順序與程序的順序相同）。
對於long和double型變量的特殊規則
Java內存模型要求lock、unlock、read、load、assign、use、store、write這8個操作都具有原子性，但是對於64位的數據類型（long和double），在模型中特別定義了一條相對寬松的規定：允許虛擬機將沒有被volatile修飾的64位數據的讀寫操作劃分為兩次32位的操作來進行，即允許虛擬機實現選擇可以不保證64位數據類型的load、store、read和write這4個操作的原子性，這點就是所謂的long和double的非原子性協定（Not atomic Treatment of double and long Variables）。
如果有多個線程共享一個並未聲明為volatile的long或double類型的變量，並且同時對它們進行讀取和修改操作，那麼某些線程可能會讀取到一個即非原值，也不是其它線程修改值得代表了“半個變量”的數值。
Java內存模型雖然允許虛擬機不把long和double變量的讀寫實現成原子操作，但允許虛擬機選擇把這些操作實現為具有原子性的操作，而且還“強烈建議”虛擬機這樣實現。在實際開發中，目前各種平台下的商用虛擬機幾乎都選擇把64位數據的讀寫操作作為原子操作來對待，因此我們在編寫代碼時一般不需要把用到的long和double變量專門聲明為volatile。
原子性、可見性和有序性
原子性（Atomicity）：由Java內存模型來直接保證的原子性變量操作包括read、load、assign、use、store、write，我們大致可以認為基本數據類型的訪問讀寫是具備原子性的（例外就是long和double的非原子性協定）。
Java內存模型還提供了lock和unlock操作來滿足這種需求，盡管虛擬機未把lock和unlock操作直接開放給用戶使用，但是卻提供了更高層次的字節碼指令monitorenter和monitorexit來隱式地使用這兩個操作，這兩個字節碼指令反映到Java代碼中就是同步塊--Synchronized關鍵字，因此在Synchronized塊之間的操作也具備原子性。
可見性（Visibility）：可見性是指當一個線程修改了共享變量的值，其它線程能夠立即得知這個修改。Java內存模型是通過在變量修改後將新值同步回主內存，在變量讀取前從主內存刷新變量值這種依賴主內存作為傳遞媒介的方法來實現可見性的，無論是普通變量還是volatile變量都是如此，普通變量與volatile變量的區別是，volatile的特殊規則保證了新值能立即同步到主內存，以及每次使用前立即從主內存刷新。因此，可以說volatile保證了多線程操作時變量的可見性，而普通變量則不能保證這一點。
除了volatile之外，Java中Synchronized和final也能實現可見性。同步塊的可見性是由“對一個變量執行unlock操作之前，必須先把此變量同步回主內存中（執行store、write操作）”這條規則獲得的，final關鍵字的可見性是指：被final修飾的字段在構造器中一旦初始化完成，並且構造器沒有把“this”的引用傳遞出去（this引用逃逸是一件很危險的事情，其它線程有可能通過這個引用訪問到“初始化了一半”的對象），那在其它線程中就能看見final字段的值。
有序性（Ordering）：如果在本線程內觀察，所有的操作都是有序的；如果在一個線程中觀察另一個線程，所有的操作都是無序的。前半句是指“線程內表現為串行的語義”（Within-Thread As-If-Serial Semantics），後半句是指“指令重排序”現象和“工作內存與主內存同步延遲”現象。
Java中volatile和Synchronized這兩個關鍵字保證線程之間操作的有序性，volatile關鍵字本身就包含了禁止指令重排序的語義，而Synchronized則是由“一個變量在同一時刻只允許一條線程對其進行lock操作”這條規則獲得的，這條規則決定了持有同一個鎖的兩個同步塊只能串行地進入。
Synchronized關鍵字在需要這3種特性的時候都可以作為其中一種的解決方案。
先行發生（happens-before）原則
這個原則非常重要，它是判斷數據是否存在競爭、線程是否安全的主要依據，依靠這個原則，我們可以通過幾條規則一攬子地解決並發環境下兩個操作之間是否可能存在沖突的所有問題。
先行發生是Java內存模型中定義的兩項操作之間的偏序關系，如果說操作A先行發生於操作B，其實就是說在發生操作B之前，操作A產生的影響能被操作B觀察到，“影響”包括修改了內存中共享變量的值、發送了消息、調用了方法等。
程序次序規則（Program Order Rule）：在一個線程內，按照程序代碼順序，書寫在前面的操作先行發生於書寫在後面的操作。准確地說，應該是控制流順序而不是程序代碼順序，因為要考慮分支，循環等結構。
管程鎖定規則（Monitor Lock Rule）：一個unlock操作先行發生於後面對同一個鎖的lock操作。這裡必須強調的是同一個鎖，而“後面”是指時間上的先後順序。
volatile變量規則（Volatile Variable Rule）：對一個volatile變量的寫操作先行發生於後面對這個變量的讀操作，這裡的“後面”同樣是指時間上的先後順序。
線程啟動規則（Thread Start Rule）：Thread對象的start()方法先行發生於此線程的每一個動作。
線程終止規則（Thread Termination Rule）：線程中的所有操作都先行發生於對此線程的終止檢測，我們可以通過Thread.join()方法結束、Thread.isAlive()的返回值等手段檢測到程序已經終止執行。
線程中斷規則（Thread Interrupting Rule）：對線程interrupt()方法的調用先行發生於被中斷線程的代碼檢測到中斷事件的發生，可以通過Thread.interrupted()方法檢測到是否有中斷發生。
對象終結規則（Finalizer Rule）：一個對象的初始化完成（構造函數執行結束）先行發生於ta的finalize()方法的開始。
傳遞性（Transitivity）：如果操作A先行發生於操作B，操作B先行發生於操作C，那就可以得出操作A先行發生於操作C的結論。
Java語言無需任何同步手段保障就能成立的先行發生規則就只有上面這些了。
一個操作“時間上的先發生”不代表這個操作會是“先行發生”，那如果一個操作“先行發生”是否就能推導出這個操作必定是“時間上的先發生”呢？很遺憾，這個推論也是不成立的，一個典型的例子就是多次提到的“指令重排序”。
時間先後順序與先行發生原則之間基本沒有太大的關系，所以我們衡量並發安全問題的時候不要受到時間順序的干擾，一切必須以先行發生原則為准。
