Java理論與實踐:正確使用Volatile變數

技術小阿哥發表於2017-11-27
Java變數

Java 語言中的 volatile 變數可以被看作是一種 “程度較輕的 synchronized”；與 synchronized 塊相比，volatile 變數所需的編碼較少，並且執行時開銷也較少，但是它所能實現的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile 變數的模式，並強調了幾種不適合使用 volatile 變數的情形。

鎖提供了兩種主要特性：互斥（mutual exclusion） 和可見性（visibility）。互斥 即一次只允許一個執行緒持有某個特定的鎖，因此可使用該特性實現對共享資料的協調訪問協議，這樣，一次就只有一個執行緒能夠使用該共享資料。可見性要更加複雜 一些，它必須確保釋放鎖之前對共享資料做出的更改對於隨後獲得該鎖的另一個執行緒是可見的 —— 如果沒有同步機制提供的這種可見性保證，執行緒看到的共享變數可能是修改前的值或不一致的值，這將引發許多嚴重問題。

Volatile 變數

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

出於簡易性或可伸縮性的考慮，您可能傾向於使用 volatile 變數而不是鎖。當使用 volatile 變數而非鎖時，某些習慣用法（idiom）更加易於編碼和閱讀。此外，volatile 變數不會像鎖那樣造成執行緒阻塞，因此也很少造成可伸縮性問題。在某些情況下，如果讀操作遠遠大於寫操作，volatile 變數還可以提供優於鎖的效能優勢。

正確使用 volatile 變數的條件

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

1.對變數的寫操作不依賴於當前值。

2.該變數沒有包含在具有其他變數的不變式中。

實際上，這些條件表明，可以被寫入 volatile 變數的這些有效值獨立於任何程式的狀態，包括變數的當前狀態。

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

大多數程式設計情形都會與這兩個條件的其中之一衝突，使得 volatile 變數不能像 synchronized 那樣普遍適用於實現執行緒安全。清單 1 顯示了一個非執行緒安全的數值範圍類。它包含了一個不變式 —— 下界總是小於或等於上界。

清單 1. 非執行緒安全的數值範圍類

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@NotThreadSafe 
public class NumberRange {
    private int lower, upper;
 
    public int getLower() { return lower; }
    public int getUpper() { return upper; }
 
    public void setLower(int value) { 
        if (value > upper) 
            throw new IllegalArgumentException(...);
        lower = value;
    }
 
    public void setUpper(int value) { 
        if (value < lower) 
            throw new IllegalArgumentException(...);
        upper = value;
    }
}

這種方式限制了範圍的狀態變數，因此將 lower 和 upper 欄位定義為 volatile 型別不能夠充分實現類的執行緒安全；從而仍然需要使用同步。否則，如果湊巧兩個執行緒在同一時間使用不一致的值執行 setLower 和 setUpper 的話，則會使範圍處於不一致的狀態。例如，如果初始狀態是(0, 5)，同一時間內，執行緒 A 呼叫 setLower(4) 並且執行緒 B 呼叫 setUpper(3)，顯然這兩個操作交叉存入的值是不符合條件的，那麼兩個執行緒都會通過用於保護不變式的檢查，使得最後的範圍值是 (4, 3) —— 一個無效值。至於針對範圍的其他操作，我們需要使 setLower() 和setUpper() 操作原子化 —— 而將欄位定義為 volatile 型別是無法實現這一目的的。

效能考慮

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

很難做出準確、全面的評價，例如 “X 總是比 Y 快”，尤其是對 JVM 內在的操作而言。（例如，某些情況下 VM 也許能夠完全刪除鎖機制，這使得我們難以抽象地比較 volatile 和 synchronized 的 開銷。）就是說，在目前大多數的處理器架構上，volatile 讀操作開銷非常低 —— 幾乎和非 volatile 讀操作一樣。而 volatile 寫操作的開銷要比非 volatile 寫操作多很多，因為要保證可見性需要實現記憶體界定（Memory Fence），即便如此，volatile 的總開銷仍然要比鎖獲取低。

volatile 操作不會像鎖一樣造成阻塞，因此，在能夠安全使用 volatile 的情況下，volatile 可以提供一些優於鎖的可伸縮特性。如果讀操作的次數要遠遠超過寫操作，與鎖相比，volatile 變數通常能夠減少同步的效能開銷。

正確使用 volatile 的模式

很多併發性專家事實上往往引導使用者遠離 volatile 變數，因為使用它們要比使用鎖更加容易出錯。然而，如果謹慎地遵循一些良好定義的模式，就能夠在很多場合內安全地使用 volatile 變數。要始終牢記使用 volatile 的限制 —— 只有在狀態真正獨立於程式內其他內容時才能使用 volatile —— 這條規則能夠避免將這些模式擴充套件到不安全的用例。

模式 #1：狀態標誌

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

很多應用程式包含了一種控制結構，形式為 “在還沒有準備好停止程式時再執行一些工作”，如清單 2 所示：

清單 2. 將 volatile 變數作為狀態標誌使用

1
2
3
4
5
6
7
8
9
10
11
volatile boolean shutdownRequested;
 
...
 
public void shutdown() { shutdownRequested = true; }
 
public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}


很可能會從迴圈外部呼叫 shutdown() 方法 —— 即在另一個執行緒中 —— 因此，需要執行某種同步來確保正確實現 shutdownRequested 變數的可見性。（可能會從 JMX 偵聽程式、GUI 事件執行緒中的操作偵聽程式、通過 RMI 、通過一個 Web 服務等呼叫）。然而，使用 synchronized塊編寫迴圈要比使用清單 2 所示的 volatile 狀態標誌編寫麻煩很多。由於 volatile 簡化了編碼，並且狀態標誌並不依賴於程式內任何其他狀態，因此此處非常適合使用 volatile。

這種型別的狀態標記的一個公共特性是：通常只有一種狀態轉換；shutdownRequested 標誌從 false 轉換為 true，然後程式停止。這種模式可以擴充套件到來回轉換的狀態標誌，但是隻有在轉換週期不被察覺的情況下才能擴充套件（從 false 到 true，再轉換到 false）。此外，還需要某些原子狀態轉換機制，例如原子變數。

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

缺乏同步會導致無法實現可見性，這使得確定何時寫入物件引用而不是原語值變得更加困難。在缺乏同步的情況下，可能會遇到某個物件引用的更新值（由另 一個執行緒寫入）和該物件狀態的舊值同時存在。（這就是造成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中物件引用 在沒有同步的情況下進行讀操作，產生的問題是您可能會看到一個更新的引用，但是仍然會通過該引用看到不完全構造的物件）。

實現安全釋出物件的一種技術就是將物件引用定義為 volatile 型別。清單 3 展示了一個示例，其中後臺執行緒在啟動階段從資料庫載入一些資料。其他程式碼在能夠利用這些資料時，在使用之前將檢查這些資料是否曾經發布過。

清單 3. 將 volatile 變數用於一次性安全釋出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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 變數。然後，其他執行緒可以讀取這個變數，從而隨時能夠看到最新的溫度值。

使用該模式的另一種應用程式就是收集程式的統計資訊。清單 4 展示了身份驗證機制如何記憶最近一次登入的使用者的名字。將反覆使用lastUser 引用來發布值，以供程式的其他部分使用。

清單 4. 將 volatile 變數用於多個獨立觀察結果的釋出

1
2
3
4
5
6
7
8
9
10
11
12
13
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 模式適用於將 JavaBeans 作為“榮譽結構”使用的框架。在 volatile bean 模式中，JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨立屬性的容器。volatile bean 模式的基本原理是：很多框架為易變資料的持有者（例如 HttpSession）提供了容器，但是放入這些容器中的物件必須是執行緒安全的。

在 volatile bean 模式中，JavaBean 的所有資料成員都是 volatile 型別的，並且 getter 和 setter 方法必須非常普通 —— 除了獲取或設定相應的屬性外，不能包含任何邏輯。此外，對於物件引用的資料成員，引用的物件必須是有效不可變的。（這將禁止具有陣列值的屬性，因為當陣列 引用被宣告為 volatile 時，只有引用而不是陣列本身具有 volatile 語義）。對於任何 volatile 變數，不變式或約束都不能包含 JavaBean 屬性。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean：

清單 5. 遵守 volatile bean 模式的 Person 物件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@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 變數來減少公共程式碼路徑的開銷。清單 6 中顯示的執行緒安全的計數器使用synchronized 確保增量操作是原子的，並使用 volatile 保證當前結果的可見性。如果更新不頻繁的話，該方法可實現更好的效能，因為讀路徑的開銷僅僅涉及 volatile 讀操作，這通常要優於一個無競爭的鎖獲取的開銷。

清單 6. 結合使用 volatile 和 synchronized 實現 “開銷較低的讀－寫鎖”

1
2
3
4
5
6
7
8
9
10
11
12
@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 保證讀程式碼路徑時，要比使用鎖執行全部程式碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要隨時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競爭的同步機制將變得非常困難。

結束語

與鎖相比，Volatile 變數是一種非常簡單但同時又非常脆弱的同步機制，它在某些情況下將提供優於鎖的效能和伸縮性。如果嚴格遵循 volatile 的使用條件 —— 即變數真正獨立於其他變數和自己以前的值 —— 在某些情況下可以使用 volatile 代替 synchronized 來簡化程式碼。然而，使用 volatile 的程式碼往往比使用鎖的程式碼更加容易出錯。本文介紹的模式涵蓋了可以使用 volatile 代替 synchronized 的最常見的一些用例。遵循這些模式（注意使用時不要超過各自的限制）可以幫助您安全地實現大多數用例，使用 volatile 變數獲得更佳效能。

本文轉自 www19 51CTO部落格，原文連結：http://blog.51cto.com/doujh/1830358，如需轉載請自行聯絡原作者


相關文章