JDK成長記17：Atomic類的原理—CAS+valotile-有解無憂

file

經過volatile和synchronize關鍵字的底層原理的洗禮，不知道你是否有一種感覺，要想弄明白它們的原理是一個非常難的程序，為什么費這么大的力氣要弄明白這些并發基礎知識呢？

其實是為了之后更好的掌握并發組件、并發集合這些內容，JDK中的juc（并發包）的知識大體可以分為如下幾塊:

file

并發基礎中除了volatile、synchronied、執行緒狀態變化之外，還有很重要的兩個知識CAS和AQS，而其他并發組件和集合都是基于這些知識來實作的工具而已，

這一節我們通過Atomic類來學習下它的底層原理，實際它的底層通過CAS+volatile的原理來實作的，我們來具體看看：

JDK中的CAS如何實作的？又是如何應用在Atomic中的？
CAS的自旋性能問題怎么優化？
CAS的ABA問題怎么解決？

在Java代碼中，CAS是如何應用在Atomic中的？

之前學習synchronized的時候，就接觸過CAS，CAS一般稱作Compare And Swap操作，操作流程如下：

file

上面CAS操作簡單描述可以如下：當更新一個值從E->V時，更新的時候需要讀取E最新的值N，如果發生了變化，也就是當E!=N，就不會更新成功，重新嘗試，否則更新值成功，變為V，

來看一個Demo：

private static AtomicInteger j = new AtomicInteger(0);

public static void main(String[] args) {
  for (int i = 0; i < 10; i++) {
    new Thread(() -> {
      System.out.println(AtomicIntegerDemo.j.incrementAndGet());
    }).start();
  }
}

這段程式有10個執行緒，它們可能同時更新J的值，但是輸出結果是按順序輸出了0到10的數字，這是因為在AtomicInteger底層，每個執行緒的更新都是CAS操作，它保證了多執行緒修改同一個值的原子性，

首先你可以先看一下AtomicInteger 整體脈絡：

file

根據之前分析原始碼的思想，先脈絡后細節，你應該可以看出，它核心脈絡就是一個Unsafe物件，int的value，如下

public class AtomicInteger extends Number implements java.io.Serializable {
  // setup to use Unsafe.compareAndSwapInt for updates
  private static final Unsafe unsafe = Unsafe.getUnsafe();

  private static final long valueOffset;


  static {
    try {
      valueOffset = unsafe.objectFieldOffset
        (AtomicInteger.class.getDeclaredField("value"));
    } catch (Exception ex) { throw new Error(ex); }
  }

  private volatile int value;

}

核心變數：

value是一個volatile的int值，通過volatile的可見性，可以保證有一個執行緒更新了，其他執行緒可以得到最新值，
valueOffset,類初始化的時候，來進行執行的，valueOffset，value這個欄位在AtomicInteger這個類中的偏移量，在底層，這個類是有自己對應的結構的，無論是在磁盤的.class檔案里，還是在JVM記憶體中，大概可以理解為：value這個欄位具體是在AtomicInteger這個類的哪個位置，offset，偏移量，這個是很底層的操作，是通過unsafe來實作的，剛剛在類初始化的時候，就會完成這個操作的，final的，一旦初始化完畢，就不會再變更了，
Usafe類，進行真正CAS操作的類

當通過new AtomicInteger(0)這句話創建的物件，實際是給value賦值了一個初始值0而已，（int默認就是0）

 public AtomicInteger(int initialValue) {
    value = https://www.cnblogs.com/fanmao/p/initialValue;
  }

現在你可以得到AtomicInteger的核心組件圖如下：

file

接著每個執行緒會呼叫incrementAndGet這個方法：

  public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
  }

可以看到直接呼叫了Unsafe的getAndAddInt方法，如下：

  public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
      v = getIntVolatile(o, offset);
    } while (!compareAndSwapInt(o, offset, v, v + delta));
    return v;
  }

（可以下載OpenJDK原始碼或訪問http://hg.openjdk.java.net/jdk/jdk/file/a1ee9743f4ee/jdk/src/share/classes/sun/misc/Unsafe.java）

上面這段代碼從脈絡上可以看出來，是經典的CAS操作，首先通過一次volatile讀，讀到最新的v值，之后再通過compareAndSwapInt這個方法，進行CAS操作，如果CAS操作失敗，會回傳false，while回圈繼續執行，進行自旋，重新嘗試CAS操作，如果CAS更新操作成功，回傳原值，

回傳原值之后，incrementAndGet進行了+1操作，incrementAndGet方法回傳，就會的得到更新后的值，

如下圖所示：

file

在Java代碼層面，很多Atomic原子類底層核心的原理就是CAS，有人也把這種操作稱為無鎖化，樂觀鎖，自旋鎖之類的，（稱呼這種東西是用來交流的，大家能明白就好，不要太過較真），

CAS操作每次嘗試修改的時候，就對比一下，有沒有人修改過這個值，沒有人修改，自己就修改，如果有人修改過，就重新查出來最新的值，再次重復那個程序，

而AtomicLong、AtomicLongArray、AtomicBoolean這些原子操作類和AtomicIneger底層是類似的，都是通過Unsafe類來做到CAS操作的，

file

也正是這種操作，可以保證多執行緒更新的時候的原子性，如下圖所示：

file

在JVM中的CAS如何實作的？

具體的CAS操作方法都是native的方法，是通過C++的代碼實作的，

  public native int   getIntVolatile(Object o, long offset);
  
  public final native boolean compareAndSwapInt(Object o, long offset,
                         int expected,
                         int x);

這就需要我們進一步深入JVM來看下CAS是如何實作的，我給大家找到了對應的C++代碼如下：

// unsafe.cpp
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))

 UnsafeWrapper("Unsafe_CompareAndSwapInt");

 oop p = JNIHandles::resolve(obj);

 jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);

 return (jint)(Atomic::cmpxchg(x, addr, e)) == e;

UNSAFE_END

通過觀察，可以發現，核心的CAS操作是通過Atomic::cmpxchg(x, addr, e)這個方法實作的，這個方法從名字上cmpxchg就可以猜到是compare and exchange和compare and swap(CAS)是一個意思，

但是你繼續跟蹤代碼會發現，這個Atomic::cmpxchg方法有很多實作，如下圖右側：

file

因為不同的作業系統和CPU對應的CAS指令可能有所不同，所以有了不同的CAS實作，

這里可以看一下atomic_linux_x86.inline.hpp 93行的這個實作方法，代碼如下：

#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "

inline jint   Atomic::cmpxchg  (jint   exchange_value, volatile jint*   dest, jint   compare_value) {

 int mp = os::is_MP();

 __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
          : "=a" (exchange_value)
          : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
          : "cc", "memory");

 return exchange_value;
}

上面這段代碼其實就是CAS最底層的實作方式，

首先通過is_MP 這個判斷表示是否是多核CPU處理的意思（Multi Processor ），

接著如果是的話，asm表示匯編指令，發送一條原子性的匯編指令，也就是說CAS底層實際通過類似于lock cmpxchgl 這種匯編的指令，通知CPU進行原子性的更新，這其實一個輕量的loc指令，可以讓CPU保證原子性的操作，所以說CAS是自旋鎖,是有道理的，

好了，到這里CAS在JVM層面的具體實作你應該已經了解了，接下來我們來看CAS的產生的兩個問題，

CAS的自旋無限回圈性能問題怎么優化？

不知道大家想到過沒，CAS操作有一個很大的問題，如果在高并發，多執行緒更新的時候，會造成大量執行緒進行自旋，消耗CPU資源，這樣的性能是很不好的（當然比synchronized還是要好很多的），

為了解決這一個問題，Java 8提供的一個對AtomicLong改進后的一個類，LongAdder，它具備一個分段CAS的原子操作類，讓我們來看一下它的分段CAS優化的思想

什么叫分段CAS,或者說是分段遷移呢？

意思就是，當某一個執行緒如果對一個值更新是，可以看對這個值進行分段更新，每一段叫做一個Cell，在更新每一個Cell的時候，發現說出現了很難更新它的值，出現了多次 CAS失敗了，自旋的時候，進行自動遷移段，它會去嘗試更新別的分段Cell的值，這樣的話就可以讓一個執行緒不會盲目的CAS自旋等待一個更新分段cell的值，

LongAdder正是基于這個思想來實作的，基本原理如下圖所示：

file

LongAdder先嘗試一次cas更新，如果失敗會轉而通過Cell[]的方式更新值，如果計算index的方式足夠散列，那么在并發量大的情況下，多個執行緒定位到同一個cell的概率也就越低，這有點類似于分段鎖的意思，

但是要注意的是sum方法在并發情況下sum的值不精確，reset方法不是執行緒安全的，

  public void reset() {
    Cell[] as = cells; Cell a;
    base = 0L;
   if (as != null) {
      for (int i = 0; i < as.length; ++i) {
        if ((a = as[i]) != null)
          a.value = https://www.cnblogs.com/fanmao/p/0L;
      }
    }
  }


  public long sum() {
    Cell[] as = cells; Cell a;
    long sum = base;
    if (as != null) {
      for (int i = 0; i < as.length; ++i) {
        if ((a = as[i]) != null)
          sum += a.value;
      }
    }
    return sum;

  }

關于sum不精確

sum方法的實作很簡單，其實就是 base + sum(cells)，由上述原始碼可以發現，sum執行時，最侄訓傳的是sum區域變數，初始被復制為base，而最侄訓傳時，很可能base已經被更新了，而此時區域變數sum不會更新，造成不一致，其次，這里對cell的讀取也無法保證是最后一次寫入的值，

所以，sum方法在沒有并發的情況下，可以獲得正確的結果，

關于reset不執行緒安全

因為reset方法并不是原子操作，它先將base重置成0，假設此時CPU切走執行sum，此時的sum就變成了減去base后的值，也就是說，在并發量大的情況下，執行完此方法并不能保證其他執行緒看到的是重置后的結果，所以要慎用，

在實際作業中，可根據LongAdder和AtomicLong的特點來使用這兩個工具，當需要在高并發下有較好的性能表現，且對值的精確度要求不高時，可以使用LongAdder（例如網站訪問人數計數），當需要保證執行緒安全，可允許一些性能損耗，要求高精度時，可以使用AtomicLong，LongAdder，替代AtomicLong,完全可以對心跳計數器來使用LongAdder，

CAS的ABA問題怎么解決？

最后我們聊一下CAS產生的ABA問題，

什么是ABA問題？

如果某個值一開始是A，后來變成了B，然后又變成了A，你本來期望的是值如果是第一個A才會設定新值，結果第二個A一比較也ok，也設定了新值，跟期望是不符合的，

怎么解決呢？

解決辦法也很簡單：加一個類似于版本號的東西，比如郵戳int stamp之類的，記錄更新的次數即可，比較的時候不光比較value也要比較郵戳，

所以atomic包里有AtomicStampedReference類，就是會比較兩個值的參考是否一致，如果一致，才會設定新值

你可以自己研究一下它的的原始碼，它CAS核心代碼如下：

  // AtomicStampedReference
  public boolean compareAndSet(V  expectedReference,
                 V  newReference,
                 int expectedStamp,
                 int newStamp) {

    Pair<V> current = pair;
    return
      expectedReference == current.reference &&
      expectedStamp == current.stamp &&
      ((newReference == current.reference &&
       newStamp == current.stamp) ||
       casPair(current, Pair.of(newReference, newStamp)));
  }

  private boolean casPair(Pair<V> cmp, Pair<V> val) {
    return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val);
  }

最后還要說明的一點，就是Atomic類不能保證多變數原子問題，一般的AtomicInteger，只能保證一個變數的原子性，

但是如果多個變數？你可以用AtomicReference，這個是封裝自定義物件的，多個變數可以放一個自定義物件里，然后他會檢查這個物件的參考是不是一個，（注意物件中的變數如果不是Atomic,操作的時候不保證原子性，只能保證操作AtomicReference泛型對應的這個物件的參考時是原子的，）

小結

今天，了解Atomic的類，這里給大家小結下Atomic類底層原理都是CAS，原理都是類似的，主要分為如下幾類：

1、AtomicInteger/AtomicLong/AtomicBoolean/AtomicReference是關于對變數的原子CAS更新，

2、AtomicIntegerArray/AtomicLongArray/AtomicReferenceArray是關于對陣列的原子CAS更新，

3、AtomicIntegerFieldUpdater/AtomicLongFieldUpdater/AtomicReferenceFieldUpdater<T,V>是基于反射的CAS原子更新某個類的欄位，

學完這一節你應該掌握了如下知識

CAS的java層面原理（Unsafe+volatile value）
CAS的JVM層面（C++/CPU匯編指令lock cmpxchgl前綴指令）
ABA問題、無限回圈性能問題、多變數原子更新問題
分段遷移CAS思想、郵戳版本號思想、原子參考思想

本文由博客群發一文多發等運營工具平臺 OpenWrite 發布

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/333230.html

標籤：Java

上一篇：java計算一個實體物件占用空間大小的方法分享

下一篇：Python中的面向物件的三大特征_封裝、繼承、多型