首先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 對象
@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 保證讀代碼路徑時，要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要隨時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競爭的同步機制將變得非常困難。
結束語
與鎖相比，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創建線程安全的堆棧
- public class LinkedStack<T> {
- private AtomicReference<Node<T>> stacks = new AtomicReference<Node<T>>();
- public T push(T e) {
- Node<T> oldNode, newNode;
- while (true) { //這里的處理非常的特別，也是必須如此的。
- oldNode = stacks.get();
- newNode = new Node<T>(e, oldNode);
- if (stacks.compareAndSet(oldNode, newNode)) {
- return e;
- }
- }
- }
- public T pop() {
- Node<T> oldNode, newNode;
- while (true) {
- oldNode = stacks.get();
- newNode = oldNode.next;
- if (stacks.compareAndSet(oldNode, newNode)) {
- return oldNode.object;
- }
- }
- }
- private static final class Node<T> {
- private T object;
- private Node<T> next;
- private Node(T object, Node<T> next) {
- this.object = object;
- this.next = next;
- }
- }
- }