Java多線程（一）之volatile深入分析

 volatile 變量提供了線程的可見性，並不能保證線程安全性和原子性。

什麼是線程的可見性：

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

具體看volatile的語義：

volatile相當於synchronized的弱實現，也就是說volatile實現了類似synchronized的語義，卻又沒有鎖機制。它確保對volatile字段的更新以可預見的方式告知其他的線程。

volatile包含以下語義：

（1）Java 存儲模型不會對valatile指令的操作進行重排序：這個保證對volatile變量的操作時按照指令的出現順序執行的。

（2）volatile變量不會被緩存在寄存器中（只有擁有線程可見）或者其他對CPU不可見的地方，每次總是從主存中讀取volatile變量的結果。也就是說對於volatile變量的修改，其它線程總是可見的，並且不是使用自己線程棧內部的變量。也就是在happens-before法則中，對一個valatile變量的寫操作後，其後的任何讀操作理解可見此寫操作的結果。

儘管volatile變量的特性不錯，但是volatile並不能保證線程安全的，也就是說volatile字段的操作不是原子性的，volatile變量只能保證可見性（一個線程修改後其它線程能夠理解看到此變化後的結果），要想保證原子性，目前爲止只能加鎖！

使用Volatile的原則：

應用volatile變量的三個原則：

（1）寫入變量不依賴此變量的值，或者只有一個線程修改此變量

（2）變量的狀態不需要與其它變量共同參與不變約束

（3）訪問變量不需要加鎖

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

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

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

正確使用volatile：

(內容來源於

http://www.ibm.com/developerworks/cn/java/j-jtp06197.html)

模式 #1：狀態標誌

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

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

清單 2. 將 volatile 變量作爲狀態標誌使用

                
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 變量用於一次性安全發佈

                
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 變量用於多個獨立觀察結果的發佈

                
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：

模式 #4：“volatile bean” 模式

                
@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 實現 “開銷較低的讀－寫鎖”

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

關於指令重排序與Happens-before法則

指令重排序

Java語言規範規定了JVM線程內部維持順序化語義，也就是說只要程序的最終結果等同於它在嚴格的順序化環境下的結果，那麼指令的執行順序就可能與代碼的順序不一致。這個過程通過叫做指令的重排序。指令重排序存在的意義在於：JVM能夠根據處理器的特性（CPU的多級緩存系統、多核處理器等）適當的重新排序機器指令，使機器指令更符合CPU的執行特點，最大限度的發揮機器的性能。

程序執行最簡單的模型是按照指令出現的順序執行，這樣就與執行指令的CPU無關，最大限度的保證了指令的可移植性。這個模型的專業術語叫做順序化一致性模型。但是現代計算機體系和處理器架構都不保證這一點（因爲人爲的指定並不能總是保證符合CPU處理的特性）。

Happens-before法則

Java存儲模型有一個happens-before原則，就是如果動作B要看到動作A的執行結果（無論A/B是否在同一個線程裏面執行），那麼A/B就需要滿足happens-before關係。

在介紹happens-before法則之前介紹一個概念：JMM動作（Java Memeory Model Action），Java存儲模型動作。一個動作（Action）包括：變量的讀寫、監視器加鎖和釋放鎖、線程的start()和join()。後面還會提到鎖的的。

happens-before完整規則：

（1）同一個線程中的每個Action都happens-before於出現在其後的任何一個Action。

（2）對一個監視器的解鎖happens-before於每一個後續對同一個監視器的加鎖。

（3）對volatile字段的寫入操作happens-before於每一個後續的同一個字段的讀操作。

（4）Thread.start()的調用會happens-before於啓動線程裏面的動作。

（5）Thread中的所有動作都happens-before於其他線程檢查到此線程結束或者Thread.join（）中返回或者Thread.isAlive()==false。

（6）一個線程A調用另一個另一個線程B的interrupt（）都happens-before於線程A發現B被A中斷（B拋出異常或者A檢測到B的isInterrupted（）或者interrupted()）。

（7）一個對象構造函數的結束happens-before與該對象的finalizer的開始

（8）如果A動作happens-before於B動作，而B動作happens-before與C動作，那麼A動作happens-before於C動作。