通常而言,在併發狀況下咱們必須經過必定的手段來保證數據的準確性,若是沒有作好併發控制,就可能致使髒讀、幻讀和不可重複度等一系列問題。樂觀鎖是人們爲了應付併發問題而提出的一種思想,具體的實現則有多種方式。java
樂觀鎖假設數據通常狀況下不會形成衝突,只在數據進行提交更新時,纔會正式對數據的衝突與否進行檢測,若是發現衝突了,則返回給用戶錯誤的信息,讓用戶決定如何去作。樂觀鎖適用於讀操做多的場景,能夠提升程序的吞吐量。算法
CAS(Compare And Swap)比較並交換,是一種實現了樂觀鎖思想的併發控制技術。CAS 算法的過程是:它包含 3 個參數 CAS(V,E,N),V 表示要更新的變量(內存值),E 表示舊的預期值,N 表示即將更新的預期值。當且僅當 V 值等於 E 值時,纔會將 V 的值設爲 N,若是 V 值和 E 值不一樣,說明已經有其餘線程作了更新,則當前線程什麼也不作,並返回當前 V 的真實值。整個操做是原子性的。數組
當多個線程同時使用 CAS 操做一個變量時,只有一個會勝出,併成功更新,其他均會失敗。失敗的線程不會被掛起,僅是被告知失敗,並容許再次嘗試,固然也能夠放棄本次操做,因此 CAS 算法是非阻塞的。基於上述原理,CAS 操做能夠在不借助鎖的狀況下實現合適的併發處理。安全
ABA 問題是 CAS 算法的一個漏洞。CAS 算法實現的一個重要前提是:取出內存中某時刻的數據,並在下一時刻比較並替換,在這個時間差內可能會致使數據的變化。併發
假設有兩個線程,分別要對內存中某一變量作 CAS 操做,線程一先從內存中取出值 A,線程二也從內存中取出值 A,並把值從 A 變爲 B 寫回,而後又把值從 B 變爲 A 寫回,這時候線程一進行 CAS 操做,發現內存中的值仍是 A,因而認爲和預期值一致,操做成功。儘管線程一的 CAS 操做成功,但並不表明這個過程就沒有問題。dom
ABA 問題會帶來什麼隱患呢?維基百科給出了詳細的示例:假設現有一個用單鏈表實現的堆棧,棧頂爲 A,A.next = B,現有線程一但願用 CAS 把棧頂替換爲 B,但在此以前,線程二介入,將 A、B 出棧,再壓入 D、C、A,整個過程以下性能
此時 B 處於遊離轉態,輪到線程一執行 CAS 操做,發現棧頂仍爲 A,CAS 成功,棧頂變爲 B,但實際上 B.next = null,即堆棧中只有 B 一個元素,C 和 D 並不在堆棧中,無緣無故就丟了。簡單來講,ABA 問題使咱們漏掉某一段時間的數據監控,誰知道在這段時間內會發生什麼有趣(可怕)的事呢?優化
能夠經過版本號的方式來解決 ABA 問題,每次執行數據修改操做時,都會帶上一個版本號,若是版本號和數據的版本一致,對數據進行修改操做並對版本號 +1,不然執行失敗。由於每次操做的版本號都會隨之增長,因此不用擔憂出現 ABA 問題。this
這僅僅是基於 Java 層面上的模擬,真正的實現要涉及到底層(我學不會)atom
public class TestCompareAndSwap { private static CompareAndSwap cas = new CompareAndSwap(); public static void main(String[] args) { for (int i = 0; i < 10; i++) { new Thread(new Runnable() { public void run() { // 獲取預估值 int expectedValue = cas.get(); boolean b = cas.compareAndSet(expectedValue, (int) (Math.random() * 101)); System.out.println(b); } }); } } } class CompareAndSwap { private int value; // 獲取內存值 public synchronized int get() { return value; } // 比較 public synchronized int compareAndSwap(int expectedValue, int newValue) { // 讀取內存值 int oldValue = value; // 比較 if (oldValue == expectedValue) { this.value = newValue; } return oldValue; } // 設置 public synchronized boolean compareAndSet(int expectedValue, int newValue) { return expectedValue == compareAndSwap(expectedValue, newValue); } }
原子包 java.util.concurrent.atomic 提供了一組原子類,原子類的操做具備原子性,一旦開始,就一直運行直到結束,中間不會有任何線程上下文切換。原子類的底層正是基於 CAS 算法實現線程安全。
Java 爲咱們提供了十六個原子類,能夠大體分爲如下四種:
AtomicBoolean
原子更新布爾類型,內部使用 int 類型的 value 存儲 1 和 0 表示 true 和 false,底層也是對 int 類型的原子操做
AtomicInteger
原子更新 int 類型
AtomicLong
原子更新 long 類型
AtomicReference
原子更新引用類型,經過泛型指定要操做的類
AtomicMarkableReference
原子更新引用類型,內部維護一個 Pair 類型(靜態內部類)的成員屬性,其中有一個 boolean 類型的標誌位,避免 ABA 問題
private static class Pair<T> { final T reference; final boolean mark; private Pair(T reference, boolean mark) { this.reference = reference; this.mark = mark; } static <T> Pair<T> of(T reference, boolean mark) { return new Pair<T>(reference, mark); } } private volatile Pair<V> pair;
AtomicStampedReference
原子更新引用類型,內部維護一個 Pair 類型(靜態內部類)的成員屬性,其中有一個 int 類型的郵戳(版本號),避免 ABA 問題
private static class Pair<T> { final T reference; final int stamp; private Pair(T reference, int stamp) { this.reference = reference; this.stamp = stamp; } static <T> Pair<T> of(T reference, int stamp) { return new Pair<T>(reference, stamp); } } private volatile Pair<V> pair;
AtomicIntegerArray
原子更新 int 數組中的元素
AtomicLongArray
原子更新 long 數組中的元素
AtomicReferenceArray
原子更新 Object 數組中的元素
用於解決對象的屬性的原子操做
AtomicIntegerFieldUpdater
原子更新對象中的 int 類型字段
AtomicLongFieldUpdater
原子更新對象中的 long 類型字段
AtomicReferenceFieldUpdater
原子更新對象中的引用類型字段
以前提到的三種類型的使用都比較簡單,查閱對應 API 便可,而對象屬性類型則有一些限制:
Java8 新增的原子類,使用分段的思想,把不一樣的線程 hash 到不一樣的段上去更新,最後再把這些段的值相加獲得最終的值。如下四個類都繼承自 Striped64,對併發的優化在 Striped64 中實現
LongAccumulator
long 類型的聚合器,須要傳入一個 long 類型的二元操做,能夠用來計算各類聚合操做,包括加乘等
LongAdder
long 類型的累加器,LongAccumulator 的特例,只能用來計算加法,且從 0 開始計算
DoubleAccumulator
double 類型的聚合器,須要傳入一個 double 類型的二元操做,能夠用來計算各類聚合操做,包括加乘等
DoubleAdder
double 類型的累加器,DoubleAccumulator 的特例,只能用來計算加法,且從 0 開始計算