互聯網上充斥着對Java多線程編程的介紹，每篇文章都從不同的角度介紹並總結了該領域的內容。但大部分文章都沒有說明多線程的實現本質，沒能讓開發者真正“過癮”。上篇內容從Java的線程安全鼻祖內置鎖介紹開始，讓你瞭解內置鎖的實現邏輯和原理以及引發的性能問題，本篇接着說明Java多線程編程中鎖的存在是爲了保障共享變量的線程安全使用。下面讓我們進入正題。
以下內容如無特殊說明均指代Java環境。
第二部分：共享對象
使用Java編寫線程安全的程序關鍵在於正確的使用共享對象，以及安全的對其進行訪問管理。在第一章我們談到Java的內置鎖可以保障線程安全，對於其他的應用來說併發的安全性是在內置鎖這個“黑盒子”內保障了線程變量使用的邊界。談到線程的邊界問題，隨之而來的是Java內存模型另外的一個重要的含義，可見性。Java對可見性提供的原生支持是volatile關鍵字。
volatile關鍵字
volatile關鍵字是Java語言提供的原生實現，可以理解爲“易變的”。首先看一個例子：
public class Share { private static boolean ready; private static int number; private static class Node extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); } } public static void main(String[] args) { new Node().start(); number = 10; ready = true; } }代碼2.1：變量的可見性問題
在代碼2.1中，可以看到按照正常的邏輯應該打印10之後線程停止，但是實際的情況可能是打印出0或者程序永遠不會被終止掉。其原因是沒有使用恰當的同步機制以保障線程的寫入操作對所有線程都是可見的。
我們一般將volatile理解爲synchronized的輕量級實現，在多核處理器中可以保障共享變量的“可見性”，但是不能保障原子性。關於原子性問題在該章節的程序變量規則會加以說明，下面我們先看下Java的內存模型實現以瞭解JVM和計算機硬件是如何協調共享變量的以及volatile變量的可見性。
Java內存模型
我們都知道現代計算機都是馮諾依曼結構的，所有的代碼都是順序執行的。如果計算機需要在CPU中運算某個指令，勢必就會涉及對數據的讀取和寫入操作。由於程序數據的大部分內容都是存儲在主內存（RAM）中的，在這當中就存在着一個讀取速度的問題，CPU很快而主內存相對來說（相對CPU）就會慢上很多，爲了解決這個速度階梯問題，各個CPU廠商都在CPU裏面引入了高速緩存來優化主內存和CPU的數據交互。
此時當CPU需要從主內存獲取數據時，會拷貝一份到高速緩存中，CPU計算時就可以直接在高速緩存中進行數據的讀取和寫入，提高吞吐量。當數據運行完成後，再將高速緩存的內容刷新到主內存中，此時其他CPU看到的纔是執行之後的結果，但在這之間存在着時間差。
看這個例子：
int counter = 0; counter = counter + 1;
代碼2.2：自增不一致問題
代碼2.2在運行時，CPU會從主內存中讀取counter的值，複製一份到當前CPU核心的高速緩存中，在CPU執行完成加1的指令之後，將結果1寫入高速緩存中，最後將高速緩存刷新到主內存中。這個例子代碼在單線程的程序中將正確的運行下去。
但我們試想這樣一種情況，現在有兩個線程共同運行該段代碼，初始化時兩個線程分別從主內存中讀取了counter的值0到各自的高速緩存中，線程1在CPU1中運算完成後寫入高速緩存Cache1，線程2在CPU2中運算完成後寫入高速緩存Cache2，此時counter的值在兩個CPU的高速緩存中的值都是1。
此時CPU1將值刷新到主內存中，counter的值爲1，之後CPU2將counter的值也刷新到主內存，counter的值覆蓋爲1，最終的結果計算counter爲1（正確的兩次計算結果相加應爲2）。這就是緩存不一致性問題。這會在多線程訪問共享變量時出現。
解決緩存不一致問題的方案：
通過總線鎖LOCK#方式。
通過緩存一致性協議。
圖2.1 ：緩存不一致問題
圖2.1中提到的兩種內存一致性協議都是從計算機硬件層面上提供的保障。CPU一般是通過在總線上增加LOCK#鎖的方式，鎖住對內存的訪問來達到目的，也就是阻塞其他CPU對內存的訪問，從而使只有一個CPU能訪問該主內存。因此需要用總線進行內存鎖定，可以分析得到此種做法對CPU的吞吐率造成的損害很嚴重，效率低下。
隨着技術升級帶來了緩存一致性協議，市場佔有率較大的Intel的CPU使用的是MESI協議，該協議可以保障各個高速緩存使用的共享變量的副本是一致的。其實現的核心思想是：當在多核心CPU中訪問的變量是共享變量時，某個線程在CPU中修改共享變量數據時，會通知其他也存儲了該變量副本的CPU將緩存置爲無效狀態，因此其他CPU讀取該高速緩存中的變量時，發現該共享變量副本爲無效狀態，會從主內存中重新加載。但當緩存一致性協議無法發揮作用時，CPU還是會降級使用總線鎖的方式進行鎖定處理。
一個小插曲：爲什麼volatile無法保障的原子性
我們看下圖2.2，CPU在主內存中讀取一個變量之後，拷貝副本到高速緩存，CPU在執行期間雖然識別了變量的“易變性”，但是隻能保障最後一步store操作的原子性，在load，use期間並未實現其原子性操作。
圖2.2：數據加載和內存屏障
JVM爲了使我們的代碼得到最優的執行體驗，在進行自我優化時，並不保障代碼的先後執行順序（滿足Happen-Before規則的除外），這就是“指令重排”，而上面提到的store操作保障了原子性，JVM是如何實現的呢？其原因是這裏存在一個“內存屏障”的指令（以後我們會談到整個內容），這個是CPU支持的一個指令，該指令只能保障store時的原子性，但是不能保障整個操作的原子性。
從整個小插曲中，我們看到了volatile雖然有可見性的語義，但是並不能真正的保證線程安全。如果要保證併發線程的安全訪問，需要符合併發程序變量的訪問規則。
併發程序變量的訪問規則
1. 原子性
程序的原子性和數據庫事務的原子性有着同樣的意義，可以保障一次操作要麼全部執行成功，要不全部都不執行。
2. 可見性
可見性是微妙的，因爲最終的結果總是和我們的直覺大相徑庭，當多個線程共同修改一個共享變量的值時，由於存在高速緩存中的變量副本操作，不能及時將數據刷新到主內存，導致當前線程在CP中的操作結果對其他CPU是不可見狀態。
3. 有序性
有序性通俗的理解就是程序在JVM中是按照順序執行的，但是前面已經提到了JVM爲了優化代碼的執行速度，會進行“指令重排”。在單線程中“指令重排”並不會帶來安全問題，但在併發程序中，由於程序的順序不能保障，運行過程中可能會出現不安全的線程訪問問題。
綜上，要想在併發編程環境中安全的運行程序，就必須滿足原子性、可見性和有序性。只要以上任何一點沒有保障，那程序運行就可能出現不可預知的錯誤。最後我們介紹一下Java併發的“殺手鐗”，Happens-Before法則，符合該法則的情況下可以保障併發環境下變量的訪問規則。
Happens-Before法則：
程序次序法則：線程中的每個動作A都Happens-Before於該線程中的每一個動作B，在程序中，所有的動作B都出現在動作A之後。
Lock法則：對於一個Lock的解鎖操作總是Happens-Before於每一個後續對該Lock的加鎖操作。
volatile變量法則：對於volatile變量的寫入操作Happens-Before於後續對同一個變量的讀操作。
線程啓動法則：在一個線程裏，對Thread.start()函數的調用會Happens-Before於每一個啓動線程中的動作。
線程終結法則：線程中的任何動作都Happens-Before於其他線程檢測到這個線程已經終結或者從Thread.join()函數調用中成功返回或者Thread.isAlive()函數返回false。
中斷法則：一個線程調用另一個線程的interrupt總是Happens-Before於被中斷的線程發現中斷。
終結法則：一個對象的構造函數的結束總是Happens-Before於這個對象的finalizer（Java沒有直接的類似C的析構函數）的開始。
傳遞性法則：如果A事件Happens-Before於B事件，並且B事件Happens-Before於C事件，那麼A事件Happens-Before於C事件。
當一個變量在多線程競爭中被讀取和存儲，如果並未按照Happens-Before的法則，那麼他就會存在數據競爭關係。
總結
關於Java的共享變量的內容就介紹到這裏，現在你已經明白Java的volatile關鍵字的含義了，瞭解了爲什麼volatile不能保障原子性的原因了，瞭解了Happens-Before規則能讓我們的Java程序運行的更加安全。
通過這兩節內容希望可以幫助你更深入的瞭解Java的併發概念中的內置鎖和共享變量。Java的併發內容還有很多，例如在某些場景下比synchronized效率要更高的Lock，阻塞隊列，同步器等。