輕量級的同步機制——volatile語義詳解(可見性保證+禁止指令重排)

目錄

• 1.關於volatile
• 2.語義一:內存可見性
  • 2.1 一個例子
  • 2.2 java的內存模型(JMM)
  • 2.3 happens-before規則
  • 2.4 volatile解決內存可見性問題的原理
• 3. 語義二：禁止指令重排
  • 3.1 爲何會有指令重排
  • 3.2 線程不安全的雙重檢查單例模式
• 4. volatile的其餘特性
• 5.總結

1.關於volatile

volatile是java語言中的關鍵字,用來修飾會被多線程訪問的共享變量,是JVM提供的輕量級的同步機制,相比同步代碼塊或者重入鎖有更好的性能。它主要有兩重語義，一是保證多個線程對共享變量訪問的可見性，二防止指令重排序。

2.語義一:內存可見性

2.1 一個例子

public class TestVolatile {

    public static void main(String[] args) throws InterruptedException {

        ThreadDemo threadDemo = new ThreadDemo();
        new Thread(threadDemo).start();
        threadDemo.flag = false;
        System.out.println("已將flag置爲" + threadDemo.flag);

    }

    static class ThreadDemo implements Runnable {

        boolean flag = true;

        @Override
        public void run() {
            System.out.println("Flag=" + flag);
        }

    }
}

當你屢次執行代碼時,有必定概率會出現這種結果

在主線程將子線程實例的flag置爲false後,子線程中的flag居然仍是true。這是怎麼回事？這就是多線程的內存可見性問題。對於一個沒有volatile修飾的的共享變量,當一個線程對其進行了修改，另外一線程並不必定能立刻看見這個被修改後的值。爲何會出現這種狀況呢？這就要從java的內存模型談起。

2.2 java的內存模型(JMM)

java的內存模型定義了線程和主內存之間的抽象關係,它的內容主要包括：

• 主要由多線程共享的主內存和各線程私有的工做內存組成(工做內存是個抽象概念，並不真實存在，是對緩衝區，cpu寄存器等的抽象)
• 變量都存儲於主內存中，可是線程的工做內存中保存着要使用的變量在主內存中的副本。
• 線程對變量的操做必須在工做內存中進行，不一樣的線程沒法直接訪問對方的工做內存，相互通訊必須通過主內存。

線程,主內存，工做內存三者的交互關係如圖所示

看看JMM模型會給咱們在多線程環境下的讀寫帶來什麼樣的問題。

• 當一個線程(線程1)對共享變量進行修改時,修改的並非主內存中的變量，而是該線程對應的工做內存中該變量的一個副本。
• 當主內存中的變量值已經被修改,另外一個線程(線程2)讀取的卻仍是本身工做內存中的舊值。

這時就出現了共享變量在多線程環境下的可見性問題。若是把線程的工做內存看成主內存的緩存，這個問題的本質就在於如何解決緩存失效問題。那麼JMM中是如何解決可見性問題的?這就不得不提到happens-before規則。

2.3 happens-before規則

happens-before規則又叫先行發生規則。它定義了java內存模型中兩項操做的偏序關係,更確切的說，它定義了操做可見性之間的偏序關係。好比A操做 happens-before B操做，並不意味這A操做必定在B操做以前,而是A操做的影響能被操做B觀察到，這個影響包括改變了內存中共享變量的值，發送消息等。那麼JMM定義了哪些happens-before規則？

• 1.程序順序規則:一個線程中的每一個操做，happens-before於該線程中的任意後續操做。
• 2.監視器鎖規則：對於一個鎖的解鎖，happens-before於隨後對這個鎖的加鎖。
• 3.volatile變量規則：對於一個volatile 變量的寫，happens-before於任意後續對這個volatile變量的讀。
  這裏對於咱們而言重要的是第三點。即對於一個volatile變量，寫操做happens-before於讀操做，也就是說，一個線程對volatile變量作了修改，另外一個線程能立刻讀到這個被修改後的值。
  這樣就能解決共享變量在多線程環境下的可見性問題了。結合JMM模型，咱們能夠繼續探討下volatile是如何作到這點的。

2.4 volatile解決內存可見性問題的原理

當一個變量被修飾爲volatile後，對其的讀寫就會顯得比較特別

• 1.寫一個volatile變量時，JMM首先修改工做內存中的變量值,並刷新到主內存中
  如圖所示
  

• 2.讀一個變量時，JMM會把該線程對應的本地內存置爲無效，並從主內存中讀取共享變量。
  如圖所示
  

對volatile變量的讀寫,能夠說都是直接對主內存進行的操做，這樣雖然會犧牲一些性能，可是解決了「緩存一致性問題」，使得變量在多線程間的可見性獲得了很好的保證。

3. 語義二：禁止指令重排

3.1 爲何會有指令重排

爲了優化程序性能,編譯器和處理器會對java編譯後的字節碼和機器指令進行重排序，通俗的說代碼的執行順序和咱們在程序中定義的順序會有些不一樣,只要不改變單線程環境下的執行結果就行。可是在多線程環境下，這麼作卻可能出現併發問題。好比下面的例子。

3.2 線程不安全的雙重檢查單例模式

運行這段代碼咱們可能會獲得一個匪夷所思的結果:咱們得到的單例對象是未初始化的。爲何會出現這種狀況？由於指令重排。首先要明確一點，同步代碼塊中的代碼也是可以被指令重排的。而後來看問題的關鍵

INSTANCE = new Singleton();

雖然在代碼中只有一行,編譯出的字節碼指令能夠用以下三行表示

• 1.爲對象分配內存空間
• 2.初始化對象
• 3.將INSTANCE變量指向剛分配的內存地址
  因爲步驟2,3交換不會改變單線程環境下的執行結果，故而這種重排序是被容許的。也就是咱們在初始化對象以前就把INSTANCE變量指向了該對象。而若是這時另外一個線程恰好執行到代碼所示的2處

if (INSTANCE == null)

那麼這時候有意思的事情就發生了:雖然INSTANCE指向了一個未被初始化的對象,可是它確實不爲null了,因此這個判斷會返回false,以後它將return一個未被初始化的單例對象！整個過程的執行流程以下圖所示

因爲重排序是編譯器和CPU自動進行的，那麼有什麼辦法能禁止這種重排序操做嗎？很簡單,給
INSTANCE變量加個volatile關鍵字就行,這樣編譯器就會根據必定的規則禁止對volatile變量的讀寫操做重排序了。而編譯出的字節碼，也會在合適的地方插入內存屏障,好比volatile寫操做以前和以後會分別插入一個StoreStore屏障和StoreLoad屏障，禁止CPU對指令的重排序越過這些屏障。

4. volatile的其餘特性

對volatile變量的讀寫具備原子性，可是其餘操做並不必定具備原子性，一個簡單的例子就是i++。因爲該操做並不具備原子性，故而即便該變量被volatile修飾，多線程環境下也不能保證線程安全。

5.總結

volatile是jvm提供的輕量級同步工具。被volatile修飾的共享變量在多線程環境下能夠得到可見行保證。其次它還能禁止指令重排。因爲對volatile的寫-讀與鎖的釋放-獲取具備相同的內存語義，故某些時候能夠代替鎖來得到更好的性能。可是和鎖不同，它不能保證任什麼時候候都是線程安全的。