volatile適用場景

volatile的適用場景

把代碼塊聲明爲 synchronized，有兩個重要後果，一般是指該代碼具備 原子性（atomicity）和 可見性（visibility）。

原子性意味着個時刻，只有一個線程可以執行一段代碼，這段代碼經過一個monitor object保護。從而防止多個線程在更新共享狀態時相互衝突。
可見性則更爲微妙，它必須確保釋放鎖以前對共享數據作出的更改對於隨後得到該鎖的另外一個線程是可見的。 —— 若是沒有同步機制提供的這種可見性保證，線程看到的共享變量多是修改前的值或不一致的值，這將引起許多嚴重問題。

volatile的使用條件
Volatile 變量具備 synchronized 的可見性特性，可是不具有原子性。這就是說線程可以自動發現 volatile 變量的最新值。

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

 

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

 

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

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

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

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

 

反例
大多數編程情形都會與這兩個條件的其中之一衝突，使得 volatile 變量不能像 synchronized 那樣廣泛適用於實現線程安全。

【反例：volatile變量不能用於約束條件中】 下面是一個非線程安全的數值範圍類。它包含了一個不變式 —— 下界老是小於或等於上界。

@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() 操做原子化。

不然，若是湊巧兩個線程在同一時間使用不一致的值執行 setLower 和 setUpper 的話，則會使範圍處於不一致的狀態。例如，若是初始狀態是(0, 5)，同一時間內，線程 A 調用setLower(4) 而且線程 B 調用setUpper(3)，顯然這兩個操做交叉存入的值是不符合條件的，那麼兩個線程都會經過用於保護不變式的檢查，使得最後的範圍值是(4, 3) —— 一個無效值。

模式 #1：狀態標誌

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

[java]  view plain  copy

 

volatile boolean shutdownRequested;  

...  

public void shutdown() {   

    shutdownRequested = true;   

}  

public void doWork() {   

while (!shutdownRequested) {   

// do stuff  

    }  

}  

 

線程1執行doWork()的過程當中，可能有另外的線程2調用了shutdown，因此boolean變量必須是volatile。

而若是使用 synchronized 塊編寫循環要比使用 volatile 狀態標誌編寫麻煩不少。因爲 volatile 簡化了編碼，而且狀態標誌並不依賴於程序內任何其餘狀態，所以此處很是適合使用 volatile。

 

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

 

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

在缺少同步的狀況下，可能會遇到某個對象引用的更新值（由另外一個線程寫入）和該對象狀態的舊值同時存在。

這就是形成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中對象引用在沒有同步的狀況下進行讀操做，產生的問題是您可能會看到一個更新的引用，可是仍然會經過該引用看到不徹底構造的對象。參見：【設計模式】5. 單例模式（以及多線程、無序寫入、volatile對單例的影響） 

[java]  view plain  copy

 

//注意volatile！！！！！！！！！！！！！！！！！    

private volatile static Singleton instace;     

public static Singleton getInstance(){     

//第一次null檢查       

if(instance == null){              

synchronized(Singleton.class) {    //1       

//第二次null檢查         

if(instance == null){          //2    

                instance = new Singleton();//3    

            }    

        }             

    }    

return instance;          

 

若是不用volatile，則由於內存模型容許所謂的「無序寫入」，可能致使失敗。——某個線程可能會得到一個未徹底初始化的實例。

考察上述代碼中的 //3 行。此行代碼建立了一個 Singleton 對象並初始化變量 instance 來引用此對象。這行代碼的問題是：在Singleton 構造函數體執行以前，變量instance 可能成爲非 null 的！
什麼？這一說法可能讓您始料未及，但事實確實如此。

在解釋這個現象如何發生前，請先暫時接受這一事實，咱們先來考察一下雙重檢查鎖定是如何被破壞的。假設上述代碼執行如下事件序列：

1.     線程 1 進入 getInstance() 方法。
2.     因爲 instance 爲 null，線程 1 在 //1 處進入synchronized 塊。
3.     線程 1 前進到 //3 處，但在構造函數執行以前，使實例成爲非null。
4.     線程 1 被線程 2 預佔。
5.     線程 2 檢查實例是否爲 null。由於實例不爲 null，線程 2 將instance 引用返回，返回一個構造完整但部分初始化了的Singleton 對象。
6.     線程 2 被線程 1 預佔。
7.     線程 1 經過運行 Singleton 對象的構造函數並將引用返回給它，來完成對該對象的初始化。

 

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

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

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

[java]  view plain  copy

 

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 模式的基本原理是：不少框架爲易變數據的持有者（例如 HttpSession）提供了容器，可是放入這些容器中的對象必須是線程安全的。

在 volatile bean 模式中，JavaBean 的全部數據成員都是 volatile 類型的，而且 getter 和 setter 方法必須很是普通——即不包含約束！

[java]  view plain  copy

 

@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;  

    }  

}  

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

若是讀操做遠遠超過寫操做，您能夠結合使用內部鎖和 volatile 變量來減小公共代碼路徑的開銷。

以下顯示的線程安全的計數器，使用 synchronized 確保增量操做是原子的，並使用 volatile 保證當前結果的可見性。若是更新不頻繁的話，該方法可實現更好的性能，由於讀路徑的開銷僅僅涉及 volatile 讀操做，這一般要優於一個無競爭的鎖獲取的開銷。

[java]  view plain  copy

 

@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;  

//讀操做，沒有synchronized，提升性能  

public int getValue() {   

return value;   

    }   

//寫操做，必須synchronized。由於x++不是原子操做  

public synchronized int increment() {  

return value++;  

    }  

使用鎖進行全部變化的操做，使用 volatile 進行只讀操做。其中，鎖一次只容許一個線程訪問值，volatile 容許多個線程執行讀操做