Java中的volatile

時間 2019-12-05

標籤 java volatile 欄目 Java 简体版

原文原文鏈接

內存可見性

只有在下列狀況時，一個線程對字段的修改才能確保對另外一個線程可見：html

一個寫操做線程釋放一個鎖以後，另外一個讀線程隨後獲取了同一個鎖。本質上，線程釋放鎖時會將強制刷新工做
內存中的數據到主內存中，獲取一個鎖將強制線程裝載（或從新裝載）字段的值。鎖提供對一個同步方法或塊的
互斥性執行，線程執行獲取鎖和釋放鎖時，全部對字段的訪問的內存效果都是已定義的。
複製代碼

注意同步的雙重含義：鎖提供高級同步協議，同時在線程執行同步方法或塊時，內存系統（有時經過內存屏障指令）保證值的一致性。這說明，與順序程序設計相比較，併發程序設計與分佈式程序設計更加相似。同步的第二個特性能夠視爲一種機制：一個線程在運行已同步方法時，它將發送或接收其餘線程在同步方法中對變量所作的修改。從這一點來講，使用鎖和發送消息僅僅是語法不一樣而已。java

若是把一個字段聲明爲volatile型，線程對這個字段值修改後，在執行後續的內存訪問以前，線程必須刷新這個字段值且讓這個字段值對其餘線程可見（即該字段當即刷新）。每次對volatile字段的讀訪問，都要從新裝載字段的值。數據庫

一個線程首次訪問一個對象的某一個字段，它將讀到這個字段的初始值或被某個線程修改後的值。編程

線程終止時，全部寫過的變量值都要刷新到主內存中。好比，一個線程使用Thread.join來終止另外一個線程，那麼第一個線程確定能看到第二個線程對變量值得修改。數組

注意，在同一個線程的不一樣方法之間傳遞對象的引用，永遠也不會出現內存可見性問題。安全

內存模型確保上述操做最終會發生，一個線程對一個特定字段的特定更新，最終將會對其餘線程可見，但這個「最終」多是很長一段時間。線程之間沒有同步時，很難保證對字段的值能在多線程之間保持一致（指寫線程對字段的寫入當即能對讀線程可見）。特別是，若是字段不是volatile或沒有經過同步來訪問這個字段，在一個循環中等待其餘線程對這個字段的寫入，這種狀況老是錯誤的。多線程

從原子性，可見性和有序性的角度分析 volatile

從原子性，可見性和有序性的角度分析，聲明爲volatile字段的做用至關於一個類經過get/set同步方法保護普通字段，以下：架構

final class VFloat {

    private float value;

    final synchronized void set(float f) { value = f; }

    final synchronized float get() { return value; }

}

複製代碼

與使用synchronized相比，聲明一個volatile字段的區別在於沒有涉及到鎖操做。但特別的是對volatile字段進行「++」這樣的讀寫操做不會被當作原子操做執行，即volatile不能保證原！子！性！。併發

另外，有序性和可見性僅對volatile字段進行一次讀取或更新操做起做用。聲明一個引用變量爲volatile，不能保證經過該引用變量訪問到的非volatile變量的可見性。同理，聲明一個數組變量爲volatile不能確保數組內元素的可見性。volatile的特性不能在數組內傳遞，由於數組裏的元素不能被聲明爲volatile。app

因爲沒有涉及到鎖操做，聲明volatile字段極可能比使用同步的開銷更低，至少不會更高。但若是在方法內頻繁訪問volatile字段，極可能致使更低的性能，這時還不如鎖住整個方法。

若是你不須要鎖，把字段聲明爲volatile是不錯的選擇，但仍須要確保多線程對該字段的正確訪問。可使用volatile的狀況包括：

該字段不遵循其餘字段的不變式。
對字段的寫操做不依賴於當前值。
沒有線程違反預期的語義寫入非法值。
讀取操做不依賴於其它非volatile字段的值。

當只有一個線程能夠修改字段的值，其它線程能夠隨時讀取，那麼把字段聲明爲volatile是合理的。例如，一個名叫Thermometer的類，能夠聲明temperature字段爲volatile。一個volatile字段很適合做爲完成某些工做的標誌。再好比，經過使用輕量級的執行框架使某些同步工做自動化，可是仍需把結果字段聲明爲volatile，使其對各個任務都是可見的。

volatile的原理

可見性實現：

在前文中已經說起過，線程自己並不直接與主內存進行數據的交互，而是經過線程的工做內存來完成相應的操做。這也是致使線程間數據不可見的本質緣由。所以要實現volatile變量的可見性，直接從這方面入手便可。對volatile變量的寫操做與普通變量的主要區別有兩點：

（1）修改volatile變量時會強制將修改後的值刷新的主內存中。

（2）修改volatile變量後會致使其餘線程工做內存中對應的變量值失效。所以，再讀取該變量值的時候就須要從新從讀取主內存中的值。

經過這兩個操做，就能夠解決volatile變量的可見性問題。

有序性實現：

在解釋這個問題前，咱們先來了解一下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（傳遞性）。

這裏咱們主要看下第三條：volatile變量的保證有序性的規則。《Java併發編程：核心理論》一文中提到太重排序分爲編譯器重排序和處理器重排序。爲了實現volatile內存語義，JMM會對volatile變量限制這兩種類型的重排序。下面是JMM針對volatile變量所規定的重排序規則表：

內存屏障

爲了實現volatile可見性和happen-befor的語義。JVM底層是經過一個叫作「內存屏障」的東西來完成。內存屏障，也叫作內存柵欄，是一組處理器指令，用於實現對內存操做的順序限制。下面是完成上述規則所要求的內存屏障：

（1）LoadLoad 屏障執行順序：Load1—>Loadload—>Load2 確保Load2及後續Load指令加載數據以前能訪問到Load1加載的數據。

（2）StoreStore 屏障執行順序：Store1—>StoreStore—>Store2 確保Store2以及後續Store指令執行前，Store1操做的數據對其它處理器可見。

（3）LoadStore 屏障執行順序： Load1—>LoadStore—>Store2 確保Store2和後續Store指令執行前，能夠訪問到Load1加載的數據。

（4）StoreLoad 屏障執行順序: Store1—> StoreLoad—>Load2 確保Load2和後續的Load指令讀取以前，Store1的數據對其餘處理器是可見的。

下面經過一個實例來講明一下JVM中是如何插入內存屏障的：

public class MemoryBarrier {
    int a, b;
    volatile int v, u;

    void f() {
        int i, j;

        i = a;
        j = b;
        i = v;
        //LoadLoad
        j = u;
        //LoadStore
        a = i;
        b = j;
        //StoreStore
        v = i;
        //StoreStore
        u = j;
        //StoreLoad
        i = u;
        //LoadLoad
        //LoadStore
        j = b;
        a = i;
    }
}
複製代碼

整體來講，volatile是併發編程中的一種優化，在某些場景下能夠代替Synchronized。可是，volatile的不能徹底取代Synchronized的位置。

性能考慮

使用 volatile 變量的主要緣由是其簡易性：在某些情形下，使用 volatile 變量要比使用相應的鎖簡單得多。使用 volatile 變量次要緣由是其性能：某些狀況下，volatile 變量同步機制的性能要優於鎖。

在目前大多數的處理器架構上，volatile 讀操做開銷很是低，幾乎和非 volatile 讀操做同樣。而 volatile 寫操做的開銷要比非 volatile 寫操做多不少，由於要保證可見性須要實現內存界定（Memory Fence），即使如此，volatile 的總開銷仍然要比鎖獲取低。

volatile 操做不會像鎖同樣形成阻塞，所以，在可以安全使用 volatile 的狀況下，volatile 能夠提供一些優於鎖的可伸縮特性。若是讀操做的次數要遠遠超過寫操做，與鎖相比，volatile 變量一般可以減小同步的性能開銷。

volatile應用場景

volatile 變量具備 synchronized 的可見性特性，可是不具有原子特性。這就是說線程可以自動發現 volatile 變量的最新值。volatile 變量可用於提供線程安全，可是隻能應用於很是有限的一組用例：多個變量之間或者某個變量的當前值與修改後值之間沒有約束。所以，單獨使用 volatile 還不足以實現計數器、互斥鎖或任何具備與多個變量相關的不變式（Invariants）的類（例如「start <=end」）。

出於簡易性或可伸縮性的考慮，您可能傾向於使用 volatile 變量而不是鎖。當使用 volatile 變量而非鎖時，某些習慣用法更加易於編碼和閱讀。此外，volatile 變量不會像鎖那樣形成線程阻塞，所以也不多形成可伸縮性問題。在某些狀況下，若是讀操做遠遠大於寫操做，volatile 變量還能夠提供優於鎖的性能優點。

正確使用 volatile 變量的條件

您只能在有限的一些情形下使用 volatile 變量替代鎖。要使 volatile 變量提供理想的線程安全，必須同時知足下面兩個條件：

對變量的寫操做不依賴於當前值。
該變量沒有包含在具備其餘變量的不變式中。

實際上，這些條件代表，能夠被寫入 volatile 變量的這些有效值獨立於任何程序的狀態，包括變量的當前狀態。

第一個條件的限制使 volatile 變量不能用做線程安全計數器。雖然增量操做（x++）看上去相似一個單獨操做，實際上它是一個由讀取－修改－寫入操做序列組成的組合操做，必須以原子方式執行，而 volatile 不能提供必須的原子特性。實現正確的操做須要使 x 的值在操做期間保持不變，而 volatile 變量沒法實現這點。（然而，若是將值調整爲只從單個線程寫入，那麼能夠忽略第一個條件。）

大多數編程情形都會與這兩個條件的其中之一衝突，使得 volatile 變量不能像 synchronized 那樣廣泛適用於實現線程安全。下面代碼顯示了一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界老是小於或等於上界。

@NotThreadSafe 
public class NumberRange {
    private int lower
    private int upper;
 
    public int getLower() { return lower; }
    public int getUpper() { return upper; }
 
    public void setLower(int value) { 
        if (value > upper) 
            throw new IllegalArgumentException("lower gt upper");
        lower = value;
    }
 
    public void setUpper(int value) { 
        if (value < lower) 
            throw new IllegalArgumentException("lower lt upper");
        upper = value;
    }
}
複製代碼

這種方式限制了範圍的狀態變量，所以將 lower 和 upper 字段定義爲 volatile 類型不可以充分實現類的線程安全；從而仍然須要使用同步。不然，若是湊巧兩個線程在同一時間使用不一致的值執行 setLower 和 setUpper 的話，則會使範圍處於不一致的狀態。例如，若是初始狀態是 (0, 5)，同一時間內，線程 A 調用 setLower(4) 而且線程 B 調用 setUpper(3)，顯然這兩個操做交叉存入的值是不符合條件的，那麼兩個線程都會經過用於保護不變式的檢查，使得最後的範圍值是 (4, 3) —— 一個無效值。至於針對範圍的其餘操做，咱們須要使 setLower() 和 setUpper() 操做原子化 —— 而將字段定義爲 volatile 類型是沒法實現這一目的的。

不少併發性專家事實上每每引導用戶遠離 volatile 變量，由於使用它們要比使用鎖更加容易出錯。然而，若是謹慎地遵循一些良好定義的模式，就可以在不少場合內安全地使用 volatile 變量。要始終牢記使用 volatile 的限制 —— 只有在狀態真正獨立於程序內其餘內容時才能使用 volatile —— 這條規則可以避免將這些模式擴展到不安全的用例。

正確使用 volatile 的模式

模式 #1：狀態標誌

也許實現 volatile 變量的規範使用僅僅是使用一個布爾狀態標誌，用於指示發生了一個重要的一次性事件，例如完成初始化或請求停機。

不少應用程序包含了一種控制結構，形式爲「在尚未準備好中止程序時再執行一些工做」，以下所示：

volatile boolean shutdownRequested;
 
...
 
public void shutdown() { shutdownRequested = true; }
 
public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}
複製代碼

極可能會從循環外部調用 shutdown() 方法 —— 即在另外一個線程中。所以，須要執行某種同步來確保正確實現 shutdownRequested 變量的可見性。然而，使用 synchronized 塊編寫循環要比上面代碼 volatile 狀態標誌編寫麻煩不少。因爲 volatile 簡化了編碼，而且狀態標誌並不依賴於程序內任何其餘狀態，所以此處很是適合使用 volatile。

這種類型的狀態標記的一個公共特性是：一般只有一種狀態轉換；shutdownRequested 標誌從 false 轉換爲 true，而後程序中止。這種模式能夠擴展到來回轉換的狀態標誌，可是隻有在轉換週期不被察覺的狀況下才能擴展（從 false 到 true，再轉換到 false）。此外，還須要某些原子狀態轉換機制，例如原子變量。

模式 #2：一次性安全發佈（one-time safe publication）

缺少同步會致使沒法實現可見性，這使得肯定什麼時候寫入對象引用而不是原語值變得更加困難。在缺少同步的狀況下，可能會遇到某個對象引用的更新值（由另外一個線程寫入）和該對象狀態的舊值同時存在。（這就是形成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中對象引用在沒有同步的狀況下進行讀操做，產生的問題是您可能會看到一個更新的引用，可是仍然會經過該引用看到不徹底構造的對象）。

DCL(double-checked-locking):


class Singleton{
    private volatile static Singleton instance = null;
     
    private Singleton() {
         
    }
     
    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}


如今咱們分析一下爲何要在變量singleton之間加上volatile關鍵字。要理解這個問題，
先要了解對象的構造過程，實例化一個對象其實能夠分爲三個步驟：
   （1）分配內存空間。
   （2）初始化對象。
   （3）將內存空間的地址賦值給對應的引用。
可是因爲操做系統能夠對指令進行重排序，因此上面的過程也可能會變成以下過程

   （1）分配內存空間。
   （2）將內存空間的地址賦值給對應的引用。
   （3）初始化對象
   
若是是這個流程，多線程環境下就可能將一個未初始化的對象引用暴露出來，從而致使不可預料的結果。
所以，爲了防止這個過程的重排序，咱們須要將變量設置爲volatile類型的變量。
複製代碼

實現安全發佈對象的一種技術就是將對象引用定義爲 volatile 類型。下面的展現的示例，其中後臺線程在啓動階段從數據庫加載一些數據。其餘代碼在可以利用這些數據時，在使用以前將檢查這些數據是否曾經發布過。

public class BackgroundFloobleLoader {
    public volatile Flooble theFlooble;
 
    public void initInBackground() {
        // do lots of stuff
        theFlooble = new Flooble();  // this is the only write to theFlooble
    }
}
 
public class SomeOtherClass {
    public void doWork() {
        while (true) { 
            // do some stuff...
            // use the Flooble, but only if it is ready
            if (floobleLoader.theFlooble != null) 
                doSomething(floobleLoader.theFlooble);
        }
    }
}
複製代碼

若是 theFlooble 引用不是 volatile 類型，doWork() 中的代碼在解除對 theFlooble 的引用時，將會獲得一個不徹底構造的 Flooble。

該模式的一個必要條件是：被髮布的對象必須是線程安全的，或者是有效的不可變對象（有效不可變意味着對象的狀態在發佈以後永遠不會被修改）。volatile 類型的引用能夠確保對象的發佈形式的可見性，可是若是對象的狀態在發佈後將發生更改，那麼就須要額外的同步。

模式 #3：獨立觀察（independent observation）

安全使用 volatile 的另外一種簡單模式是：按期「發佈」觀察結果供程序內部使用。例如，假設有一種環境傳感器可以感受環境溫度。一個後臺線程可能會每隔幾秒讀取一次該傳感器，並更新包含當前文檔的 volatile 變量。而後，其餘線程能夠讀取這個變量，從而隨時可以看到最新的溫度值。

使用該模式的另外一種應用程序就是收集程序的統計信息。下面示例展現了身份驗證機制如何記憶最近一次登陸的用戶的名字。將反覆使用 lastUser 引用來發布值，以供程序的其餘部分使用。

public class UserManager {
    public volatile String lastUser;
 
    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}
複製代碼

該模式是前面模式的擴展；將某個值發佈，在程序內的其餘地方使用，可是與一次性事件的發佈不一樣，這是一系列獨立事件。這個模式要求被髮布的值是有效不可變的 —— 即值的狀態在發佈後不會更改。使用該值的代碼須要清楚該值可能隨時發生變化。

模式 #4：「volatile bean」模式

在 volatile bean 模式中，JavaBean 被用做一組具備 getter 和/或 setter 方法的獨立屬性的容器。volatile bean 模式的基本原理是：不少框架爲易變數據的持有者（例如 HttpSession）提供了容器，可是放入這些容器中的對象必須是線程安全的。

在 volatile bean 模式中，JavaBean 的全部數據成員都是 volatile 類型的，而且 getter 和 setter 方法必須很是普通 —— 除了獲取或設置相應的屬性外，不能包含任何邏輯。此外，對於對象引用的數據成員，引用的對象必須是有效不可變的。（這將禁止具備數組值的屬性，由於當數組引用被聲明爲 volatile 時，只有引用而不是數組自己具備 volatile 語義）。對於任何 volatile 變量，不變式或約束都不能包含 JavaBean 屬性。下面展現的示例展現了遵照 volatile bean 模式的 JavaBean：

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;
 
    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }
 
    public void setFirstName(String firstName) { 
        this.firstName = firstName;
    }
 
    public void setLastName(String lastName) { 
        this.lastName = lastName;
    }
 
    public void setAge(int age) { 
        this.age = age;
    }
}
複製代碼

volatile 的高級模式

前面介紹的模式涵蓋了大部分的基本用例，在這些模式中使用 volatile 很是有用而且簡單。這一節將介紹一種更加高級的模式，在該模式中，volatile 將提供性能或可伸縮性優點。

volatile 應用的的高級模式很是脆弱。所以，必須對假設的條件仔細證實，而且這些模式被嚴格地封裝了起來，由於即便很是小的更改也會損壞您的代碼！一樣，使用更高級的 volatile 用例的緣由是它可以提高性能，確保在開始應用高級模式以前，真正肯定須要實現這種性能獲益。須要對這些模式進行權衡，放棄可讀性或可維護性來換取可能的性能收益 —— 若是您不須要提高性能（或者不可以經過一個嚴格的測試程序證實您須要它），那麼這極可能是一次糟糕的交易，由於您極可能會得不償失，換來的東西要比放棄的東西價值更低。

模式 #5：開銷較低的讀－寫鎖策略

目前爲止，您應該瞭解了 volatile 的功能還不足以實現計數器。由於 ++x 其實是三種操做（讀、添加、存儲）的簡單組合，若是多個線程湊巧試圖同時對 volatile 計數器執行增量操做，那麼它的更新值有可能會丟失。

然而，若是讀操做遠遠超過寫操做，您能夠結合使用內部鎖和 volatile 變量來減小公共代碼路徑的開銷。下面示例中顯示的線程安全的計數器使用 synchronized 確保增量操做是原子的，並使用 volatile 保證當前結果的可見性。若是更新不頻繁的話，該方法可實現更好的性能，由於讀路徑的開銷僅僅涉及 volatile 讀操做，這一般要優於一個無競爭的鎖獲取的開銷。

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;
 
    public int getValue() { return value; }
 
    public synchronized int increment() {
        return value++;
    }
}
複製代碼

之因此將這種技術稱之爲「開銷較低的讀－寫鎖」是由於您使用了不一樣的同步機制進行讀寫操做。由於本例中的寫操做違反了使用 volatile 的第一個條件，所以不能使用 volatile 安全地實現計數器 —— 您必須使用鎖。然而，您能夠在讀操做中使用 volatile 確保當前值的可見性，所以可使用鎖進行全部變化的操做，使用 volatile 進行只讀操做。其中，鎖一次只容許一個線程訪問值，volatile 容許多個線程執行讀操做，所以當使用 volatile 保證讀代碼路徑時，要比使用鎖執行所有代碼路徑得到更高的共享度 —— 就像讀－寫操做同樣。然而，要隨時牢記這種模式的弱點：若是超越了該模式的最基本應用，結合這兩個競爭的同步機制將變得很是困難。