AtomicReference與volatile的區別

標籤：

首先volatile是java中關鍵字用於修飾變數，AtomicReference是並發包java.util.concurrent.atomic下的類。
首先volatile作用，當一個變數被定義為volatile之後，看做“程度較輕的 synchronized”，具備兩個特性：
1.保證此變數對所有線程的可見度(當一條線程修改這個變數值時，新值其他線程立即得知)
2.禁止指令重新排序
注意volatile修飾變數不能保證在並發條件下是安全執行緒的，因為java裡面的運算並非原子操作。
volatile說明
java.util.concurrent.atomic工具包，支援在單個變數上解除鎖的安全執行緒編程。其基本的特性就是在多線程環境下，當有多個線程同時執行這些類的執行個體包含的方法時，具有排他性，即當某個線程進入方法，執行其中的指令時，不會被其他線程打斷，而別的線程就像自旋鎖一樣，一直等到該方法執行完成，才由JVM從等待隊列中選擇一個另一個線程進入，這隻是一種邏輯上的理解。
AtomicReference說明

 

 

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

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 變數提供理想的安全執行緒，必須同時滿足下面兩個條件：

• 對變數的寫操作不依賴於當前值。
• 該變數沒有包含在具有其他變數的不變式中。

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

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

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

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

@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 變數作為狀態標誌使用

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：

清單 5. 遵守 volatile bean 模式的 Person 對象

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

@ThreadSafepublic 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 變數獲得更佳效能。

 

 

 

java線程:Atomic原子的(轉)  

一、何謂Atomic？

 Atomic一詞跟原子有點關係，後者曾被人認為是最小物質的單位。電腦中的Atomic是指不能分割成若干部分的意思。如果一段代碼被認為是Atomic，則表示這段代碼在執行過程中，是不能被中斷的。通常來說，原子指令由硬體提供，供軟體來實現原子方法（某個線程進入該方法後，就不會被中斷，直到其執行完成）

 

 在x86 平台上，CPU提供了在指令執行期間對匯流排加鎖的手段。CPU晶片上有一條引線#HLOCK pin，如果組合語言的程式中在一條指令前面加上首碼"LOCK"，經過彙編以後的機器代碼就使CPU在執行這條指令的時候把#HLOCK pin的電位拉低，持續到這條指令結束時放開，從而把匯流排鎖住，這樣同一匯流排上別的CPU就暫時不能通過匯流排訪問記憶體了，保證了這條指令在多處理器環境中的原子性。

 

二、JDK1.5的原子包：java.util.concurrent.atomic

這個包裡面提供了一組原子類。其基本的特性就是在多線程環境下，當有多個線程同時執行這些類的執行個體包含的方法時，具有排他性，即當某個線程進入方法，執行其中的指令時，不會被其他線程打斷，而別的線程就像自旋鎖一樣，一直等到該方法執行完成，才由JVM從等待隊列中選擇一個另一個線程進入，這隻是一種邏輯上的理解。實際上是藉助硬體的相關指令來實現的，不會阻塞線程(或者說只是在硬體層級上阻塞了)。其中的類可以分成4組

• AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
• AtomicIntegerArray，AtomicLongArray
• AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
• AtomicMarkableReference，AtomicStampedReference，AtomicReferenceArray

Atomic類的作用

• 使得讓對單一資料的操作，實現了原子化
• 使用Atomic類構建複雜的，無需阻塞的代碼
  • 訪問對2個或2個以上的atomic變數（或者對單個atomic變數進行2次或2次以上的操作）通常認為是需要同步的，以達到讓這些操作能被作為一個原子單元。

2.1 AtomicBoolean , AtomicInteger, AtomicLong, AtomicReference

這四種基本類型用來處理布爾，整數，長整數，對象四種資料。

• 建構函式（兩個建構函式）
  • 預設的建構函式：初始化的資料分別是false，0，0，null
  • 帶參建構函式：參數為初始化的資料
• set( )和get( )方法：可以原子地設定和擷取atomic的資料。類似於volatile，保證資料會在主存中設定或讀取
• getAndSet( )方法
  • 原子的將變數設定為新資料，同時返回先前的舊資料
  • 其本質是get( )操作，然後做set( )操作。儘管這2個操作都是atomic，但是他們合并在一起的時候，就不是atomic。在Java的來源程式的層級上，如果不依賴synchronized的機制來完成這個工作，是不可能的。只有依靠native方法才可以。
• compareAndSet( ) 和weakCompareAndSet( )方法
  • 這兩個方法都是conditional modifier方法。這2個方法接受2個參數，一個是期望資料(expected)，一個是新資料(new)；如果atomic裡面的資料和期望資料一致，則將新資料設定給atomic的資料，返回true，表明成功；否則就不設定，並返回false。
• 對於AtomicInteger、AtomicLong還提供了一些特別的方法。getAndIncrement( )、incrementAndGet( )、getAndDecrement( )、decrementAndGet ( )、addAndGet( )、getAndAdd( )以實現一些加法，減法原子操作。(注意 --i、++i不是原子操作，其中包含有3個操作步驟：第一步，讀取i；第二步，加1或減1；第三步：寫回記憶體)

2.1.1 1個例子-使用AtomicReference建立安全執行緒的堆棧

 

Java代碼 

1. public class LinkedStack<T> {   
2.   
3.     private AtomicReference<Node<T>> stacks = new AtomicReference<Node<T>>();   
4.   
5.     public T push(T e) {   
6.         Node<T> oldNode, newNode;   
7.         while (true) { //這裡的處理非常的特別，也是必須如此的。   
8.             oldNode = stacks.get();   
9.             newNode = new Node<T>(e, oldNode);   
10.             if (stacks.compareAndSet(oldNode, newNode)) {   
11.                 return e;   
12.             }   
13.         }   
14.     }   
15.        
16.     public T pop() {   
17.         Node<T> oldNode, newNode;   
18.         while (true) {   
19.             oldNode = stacks.get();   
20.             newNode = oldNode.next;   
21.             if (stacks.compareAndSet(oldNode, newNode)) {   
22.                 return oldNode.object;   
23.             }   
24.         }   
25.     }   
26.   
27.     private static final class Node<T> {   
28.         private T object;   
29.            
30.         private Node<T> next;   
31.   
32.         private Node(T object, Node<T> next) {   
33.             this.object = object;   
34.             this.next = next;   
35.         }   
36.     }   
37. }  

AtomicReference與volatile的區別