volatile的使用及其原理

1、 volatile的作用

相比Sychronized（重量級鎖，對系統性能影響較大），volatile提供了另一種解決 可見性和有序性 ？？？問題的方案。對於原子性，需要強調一點，也是大家容易誤解的一點：對volatile變量的單次讀/寫操作可以保證原子性的，如long和double類型變量，但是並不能保證i++這種操作的原子性，因為本質上 i++ 是讀、寫兩次操作。

2、volatile的使用

1、防重排序

我們從一個最經典的例子來分析 重排序問題？？？。大家應該都很熟悉 單例模式 的實現，而在並發環境下的單例實現方式，我們通常可以采用  雙重檢查加鎖（DCL） ？？？的方式來實現。其源碼如下：

public class Singleton {
    public static volatile Singleton singleton;
    /**
     * 構造函數私有，禁止外部實例化
     */
    private Singleton() {};
    public static Singleton getInstance() {
        if (singleton == null) {
            synchronized (singleton) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

現在我們分析一下為什么要在變量singleton之間加上volatile關鍵字。要理解這個問題，先要了解對象的構造過程，實例化一個對象其實可以分為三個步驟： 
　　（1）分配內存空間。 
　　（2）初始化對象。 
　　（3）將內存空間的地址賦值給對應的引用。 
但是由於操作系統可以對指令進行重排序，所以上面的過程也可能會變成如下過程： 
　　（1）分配內存空間。 
　　（2）將內存空間的地址賦值給對應的引用。 
　　（3）初始化對象 
　　如果是這個流程，多線程環境下就可能將一個未初始化的對象引用暴露出來，從而導致不可預料的結果。因此，為了防止這個過程的重排序，我們需要將變量設置為volatile類型的變量。

2、實現可見性

可見性問題主要指一個線程修改了共享變量值，而另一個線程卻看不到。引起可見性問題的主要原因是每個線程擁有自己的一個高速緩存區——線程工作內存。volatile關鍵字能有效的解決這個問題，我們看下下面的例子，就可以知道其作用：

 

public class VolatileTest {
    int a = 1;
    int b = 2;

    public void change(){
        a = 3;
        b = a;
    }

    public void print(){
        System.out.println("b="+b+";a="+a);
    }

    public static void main(String[] args) {
        while (true){
            final VolatileTest test = new VolatileTest();
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test.change();
                }
            }).start();
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test.print();
                }
            }).start();
        }
    }
}

直觀上說，這段代碼的結果只可能有兩種：b=3;a=3 或 b=2;a=1。不過運行上面的代碼（可能時間上要長一點），你會發現除了上兩種結果之外，還出現了第三種結果：

...... 
b=2;a=1
b=2;a=1
b=3;a=3
b=3;a=3
b=3;a=1
b=3;a=3
b=2;a=1
b=3;a=3
b=3;a=3
......

為什么會出現b=3;a=1這種結果呢？正常情況下，如果先執行change方法，再執行print方法，輸出結果應該為b=3;a=3。相反，如果先執行的print方法，再執行change方法，結果應該是 b=2;a=1。那b=3;a=1的結果是怎么出來的？原因就是第一個線程將值a=3修改后，但是對第二個線程是不可見的，所以才出現這一結果。如果將a和b都改成volatile類型的變量再執行，則再也不會出現b=3;a=1的結果了。

3、保證原子性

關於原子性的問題，上面已經解釋過。volatile只能保證對單次讀/寫的原子性。這個問題可以看下JLS中的描述：

17.7 Non-Atomic Treatment of double and long 
For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write. 
Writes and reads of volatile long and double values are always atomic. 
Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values. 
Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32-bit values. For efficiency’s sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and double values atomically or in two parts. 
Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

這段話的內容跟我前面的描述內容大致類似。因為long和double兩種數據類型的操作可分為高32位和低32位兩部分，因此普通的long或double類型讀/寫可能不是原子的。因此，鼓勵大家將共享的long和double變量設置為volatile類型，這樣能保證任何情況下對long和double的單次讀/寫操作都具有原子性。 
　　關於volatile變量對原子性保證，有一個問題容易被誤解。現在我們就通過下列程序來演示一下這個問題：

public class VolatileTest01 {
    volatile int i;

    public void addI(){
        i++;
    }

    public static void main(String[] args) throws InterruptedException {
        final  VolatileTest01 test01 = new VolatileTest01();
        for (int n = 0; n < 1000; n++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    test01.addI();
                }
            }).start();
        }
        Thread.sleep(10000);//等待10秒，保證上面程序執行完成
        System.out.println(test01.i);
    }
}

大家可能會誤認為對變量i加上關鍵字volatile后，這段程序就是線程安全的。大家可以嘗試運行上面的程序。下面是我本地運行的結果：981 
可能每個人運行的結果不相同。不過應該能看出，volatile是無法保證原子性的（否則結果應該是1000）。原因也很簡單，i++其實是一個復合操作，包括三步驟： 
　　（1）讀取i的值。 
　　（2）對i加1。 
　　（3）將i的值寫回內存。 
volatile是無法保證這三個操作是具有原子性的，我們可以通過 AtomicInteger 或者 Synchronized 來保證+1操作的原子性。 
注：上面幾段代碼中多處執行了Thread.sleep()方法，目的是為了增加並發問題的產生幾率，無其他作用。

3、volatile的原理

通過上面的例子，我們基本應該知道了volatile是什么以及怎么使用。現在我們再來看看volatile的底層是怎么實現的。

1、可見性實現：

　　在前文中已經提及過，線程本身並不直接與主內存進行數據的交互，而是通過線程的工作內存來完成相應的操作。這也是導致線程間數據不可見的本質原因。因此要實現volatile變量的可見性，直接從這方面入手即可。對volatile變量的寫操作與普通變量的主要區別有兩點： 
　　（1）修改volatile變量時會強制將修改后的值刷新的主內存中。 
　　（2）修改volatile變量后會導致其他線程工作內存中對應的變量值失效。因此，再讀取該變量值的時候就需要重新從讀取主內存中的值。 
　　通過這兩個操作，就可以解決volatile變量的可見性問題。

2、有序性實現：

　　在解釋這個問題前，我們先來了解一下Java中的happen-before規則，JSR 133中對Happen-before的定義如下：

Two actions can be ordered by a happens-before relationship.If one action happens before another, then the first is visible to and ordered before the second.

通俗一點說就是如果a happen-before b，則a所做的任何操作對b是可見的。（這一點大家務必記住，因為happen-before這個詞容易被誤解為是時間的前后）。我們再來看看JSR 133中定義了哪些happen-before規則：

• Each action in a thread happens before every subsequent action in that thread. 
• An unlock on a monitor happens before every subsequent lock on that monitor. 
• A write to a volatile field happens before every subsequent read of that volatile. 
• A call to start() on a thread happens before any actions in the started thread. 
• All actions in a thread happen before any other thread successfully returns from a join() on that thread. 
• If an action a happens before an action b, and b happens before an action c, then a happens before c.

翻譯過來為：

• 同一個線程中的，前面的操作 happen-before 后續的操作。（即單線程內按代碼順序執行。但是，在不影響在單線程環境執行結果的前提下，編譯器和處理器可以進行重排序，這是合法的。換句話說，這一是規則無法保證編譯重排和指令重排）。
• 監視器上的解鎖操作 happen-before 其后續的加鎖操作。（Synchronized 規則）
• 對volatile變量的寫操作 happen-before 后續的讀操作。（volatile 規則）
• 線程的start() 方法 happen-before 該線程所有的后續操作。（線程啟動規則）
• 線程所有的操作 happen-before 其他線程在該線程上調用 join 返回成功后的操作。
• 如果 a happen-before b，b happen-before c，則a happen-before c（傳遞性）。

4、volatile的使用優化

著名的Java並發編程大師Doug lea在JDK 7的並發包里新增一個隊列集合類LinkedTransferQueue，它在使用volatile變量時，用一種追加字節的方式來優化隊列出隊和入隊的性能。LinkedTransferQueue的代碼如下：

/** 隊列中的頭部節點 */
private transient final PaddedAtomicReference<QNode> head;
/** 隊列中的尾部節點 */
private transient final PaddedAtomicReference<QNode> tail;
static final class PaddedAtomicReference <T> extends AtomicReference T> {
     // 使用很多4個字節的引用追加到64個字節
     Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe;
     PaddedAtomicReference(T r) {
        super(r);
     }
}
public class AtomicReference <V> implements java.io.Serializable {
     private volatile V value;
     // 省略其他代碼
｝

追加字節能優化性能？這種方式看起來很神奇，但如果深入理解處理器架構就能理解其中的奧秘。讓我們先來看看LinkedTransferQueue這個類，它使用一個內部類類型來定義隊列的頭節點（head）和尾節點（tail），而這個內部類PaddedAtomicReference相對於父類AtomicReference只做了一件事情，就是將共享變量追加到64字節。我們可以來計算下，一個對象的引用占4個字節，它追加了15個變量（共占60個字節），再加上父類的value變量，一共64個字節。 
為什么追加64字節能夠提高並發編程的效率呢？因為對於英特爾酷睿i7、酷睿、Atom和NetBurst，以及Core Solo和Pentium M處理器的L1、L2或L3緩存的高速緩存行是64個字節寬，不支持部分填充緩存行，這意味着，如果隊列的頭節點和尾節點都不足64字節的話，處理器會將它們都讀到同一個高速緩存行中，在多處理器下每個處理器都會緩存同樣的頭、尾節點，當一個處理器試圖修改頭節點時，會將整個緩存行鎖定，那么在緩存一致性機制的作用下，會導致其他處理器不能訪問自己高速緩存中的尾節點，而隊列的入隊和出隊操作則需要不停修改頭節點和尾節點，所以在多處理器的情況下將會嚴重影響到隊列的入隊和出隊效率。Doug lea使用追加到64字節的方式來填滿高速緩沖區的緩存行，避免頭節點和尾節點加載到同一個緩存行，使頭、尾節點在修改時不會互相鎖定。 
那么是不是在使用volatile變量時都應該追加到64字節呢？不是的。在兩種場景下不應該使用這種方式。

• 緩存行非64字節寬的處理器。如P6系列和奔騰處理器，它們的L1和L2高速緩存行是32個字節寬。
• 共享變量不會被頻繁地寫。因為使用追加字節的方式需要處理器讀取更多的字節到高速緩沖區，這本身就會帶來一定的性能消耗，如果共享變量不被頻繁寫的話，鎖的幾率也非常小，就沒必要通過追加字節的方式來避免相互鎖定。

參考： 
Java 並發編程：volatile的使用及其原理 
就是要你懂Java中volatile關鍵字實現原理

參考文檔： https://blog.csdn.net/devotion987/article/details/68486942