2. 程式人生 > 程式設計 >JUC之深入分析 CAS

JUC之深入分析 CAS

阿新 • • 發佈：2019-12-31

概述

CAS ，Compare And Swap ，即比較並交換。Doug Lea 大神在實現同步元件時，大量使用CAS 技術，鬼斧神工地實現了Java 多執行緒的併發操作。

整個 AQS 同步元件、Atomic 原子類操作等等都是基 CAS 實現的，甚至 ConcurrentHashMap 在 JDK 1.8 的版本中，也調整為 CAS + synchronized 。可以說，CAS 是整個 J.U.C 的基石。

CAS分析

在 CAS 中有三個引數：記憶體值 V、舊的預期值 A、要更新的值 B ，當且僅當記憶體值 V 的值等於舊的預期值 A 時，才會將記憶體值V的值修改為 B ，否則什麼都不幹。其虛擬碼如下：

if (this.value == A) {
	this.value = B
	return true;
} else {
	return false;
}
複製程式碼

J.U.C 下的 Atomic 類，都是通過 CAS 來實現的。下面就以 AtomicInteger 為例，來闡述 CAS 的實現。如下：

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;
複製程式碼

Unsafe 是 CAS 的核心類，Java 無法直接訪問底層作業系統，而是通過本地 native 方法來訪問。

不過儘管如此，JVM還是開了一個後門：Unsafe ，它提供了硬體級別的原子操作。

valueOffset 為變數值在記憶體中的偏移地址，Unsafe 就是通過偏移地址來得到資料的原值的。 value 當前值，使用 volatile 修飾，保證多執行緒環境下看見的是同一個。

AtomicInteger

我們就以 AtomicInteger 的 #addAndGet() 方法來做說明，先看原始碼：

// AtomicInteger.java
public final int addAndGet(int delta) {
    return unsafe.getAndAddInt(this,valueOffset,delta) + delta;
}

// Unsafe.java
public final int getAndAddInt(Object var1,long var2,int var4) {
    int var5;
    do {
        var5 = this.getIntVolatile(var1,var2);
    } while(!this.compareAndSwapInt(var1,var2,var5,var5 + var4));

    return var5;
}
複製程式碼

內部呼叫 unsafe 的 #getAndAddInt(Object var1,long var2,int var4)方法，在#getAndAddInt(Object var1,int var4) 方法中，主要是看 #compareAndSwapInt(Object var1,int var4,int var5) 方法，程式碼如下：

public final native boolean compareAndSwapInt(Object var1,int var5);
複製程式碼

該方法為本地方法，有四個引數，分別代表：物件、物件的地址、預期值、修改值

CPU 原子操作

CAS 可以保證一次的讀-改-寫操作是原子操作，在單處理器上該操作容易實現，但是在多處理器上實現就有點兒複雜了。

CPU 提供了兩種方法來實現多處理器的原子操作：匯流排加鎖或者快取加鎖。

  1. 匯流排加鎖：匯流排加鎖就是就是使用處理器提供的一個 LOCK# 訊號，當一個處理器在匯流排上輸出此訊號時，其他處理器的請求將被阻塞住，那麼該處理器可以獨佔使用共享記憶體。但是這種處理方式顯得有點兒霸道，不厚道，他把CPU和記憶體之間的通訊鎖住了，在鎖定期間，其他處理器都不能使用其他記憶體地址的資料，其開銷有點兒大。所以就有了快取加鎖。

  2. 快取加鎖：其實針對於上面那種情況，我們只需要保證在同一時刻，對某個記憶體地址的操作是原子性的即可。快取加鎖，就是快取在記憶體區域的資料如果在加鎖期間，當它執行鎖操作寫回記憶體時，處理器不再輸 出LOCK# 訊號，而是修改內部的記憶體地址，利用快取一致性協議來保證原子性。快取一致性機制可以保證同一個記憶體區域的資料僅能被一個處理器修改，也就是說當 CPU1 修改快取行中的 i 時使用快取鎖定，那麼 CPU2 就不能同時快取了 i 的快取行。

CAS缺陷

CAS 雖然高效地解決了原子操作，但是還是存在一些缺陷的，主要表現在三個方面：

  1. 迴圈時間太長
  2. 只能保證一個共享變數原子操作
  3. ABA 問題

迴圈時間太長

如果CAS一直不成功呢？這種情況絕對有可能發生，如果自旋 CAS 長時間地不成功，則會給 CPU 帶來非常大的開銷。在 J.U.C 中，有些地方就限制了 CAS 自旋的次數，例如： BlockingQueue 的 SynchronousQueue 。

只能保證一個共享變數原子操作

看了 CAS 的實現就知道這隻能針對一個共享變數，如果是多個共享變數就只能使用鎖了，當然如果你有辦法把多個變數整成一個變數，利用 CAS 也不錯。例如讀寫鎖中 state 的高低位。

ABA問題

CAS 需要檢查操作值有沒有發生改變，如果沒有發生改變則更新。但是存在這樣一種情況：如果一個值原來是 A，變成了 B，然後又變成了 A，那麼在 CAS 檢查的時候會發現沒有改變，但是實質上它已經發生了改變，這就是所謂的ABA問題。對於 ABA 問題其解決方案是加上版本號，即在每個變數都加上一個版本號，每次改變時加 1 ，即 A —> B —> A ，變成1A —> 2B —> 3A 。

影響

用一個例子來闡述 ABA 問題所帶來的影響。

有如下連結串列如下圖：

假如我們想要把 A 替換為 B ，也就是 #compareAndSet(this,A,B) 。執行緒 1 執行 A 替換 B 操作之前，執行緒 2 先執行如下動作，A 、B 出棧，然後 C、A 入棧，最終該連結串列如下：

完成後，執行緒 1 發現仍然是 A ，那麼 #compareAndSet(this,B) 成功，但是這時會存在一個問題就是 B.next = null，因此 #compareAndSet(this,B) 後，會導致 C 丟失，改棧僅有一個 B 元素，平白無故把 C 給丟失了。

解決方案 AtomicStampedReference

CAS 的 ABA 隱患問題，解決方案則是版本號，Java 提供了 AtomicStampedReference 來解決。AtomicStampedReference 通過包裝 [E,Integer] 的元組，來對物件標記版本戳 stamp ，從而避免 ABA 問題。對於上面的案例，應該執行緒 1 會失敗。

AtomicStampedReference 的 #compareAndSet(...) 方法，程式碼如下：

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)));
}
複製程式碼

有四個方法引數，分別表示：預期引用、更新後的引用、預期標誌、更新後的標誌。原始碼部分很好理解：

  1. 預期的引用 == 當前引用
  2. 預期的標識 == 當前標識
  3. 如果更新後的引用和標誌和當前的引用和標誌相等，則直接返回 true
  4. 通過 Pair#of(T reference,int stamp) 方法，生成一個新的 Pair 物件，與當前 Pair CAS 替換。

Pair 為 AtomicStampedReference 的內部類，主要用於記錄引用和版本戳資訊（標識），定義如下：

// AtomicStampedReference.java

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;
複製程式碼

  1. Pair 記錄了物件的引用和版本戳，版本戳為 int 型，保持自增。同時 Pair 是一個不可變物件，其所有屬性全部定義為 final 。對外提供一個 #of(T reference,int stamp) 方法，該方法返回一個新建的 Pair 物件。

  2. pair 屬性，定義為 volatile ，保證多執行緒環境下的可見性。在AtomicStampedReference 中，大多方法都是通過呼叫 Pair 的 #of(T reference,int stamp) 方法，來產生一個新的 Pair 物件，然後賦值給變數 pair 。如 set(V newReference,int newStamp)方法，程式碼如下：

// AtomicStampedReference.java
public void set(V newReference,int newStamp) {
    Pair<V> current = pair;
    if (newReference != current.reference || newStamp != current.stamp)
        this.pair = Pair.of(newReference,newStamp);
}
複製程式碼

實際案例

下面，我們將通過一個例子，可以看到 AtomicStampedReference 和 AtomicInteger 的區別。我們定義兩個執行緒，執行緒 1 負責將 100 —> 110 —> 100，執行緒 2 執行 100 —>120 ，看兩者之間的區別。

public class Test {
    private static AtomicInteger atomicInteger = new AtomicInteger(100);
    private static AtomicStampedReference atomicStampedReference = new AtomicStampedReference(100,1);

    public static void main(String[] args) throws InterruptedException {

        // AtomicInteger
        Thread at1 = new Thread(new Runnable() {
            @Override
            public void run() {
                atomicInteger.compareAndSet(100,110);
                atomicInteger.compareAndSet(110,100);
            }
        });

        Thread at2 = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    TimeUnit.SECONDS.sleep(2);      // at1,執行完
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("AtomicInteger:" + atomicInteger.compareAndSet(100,120));
            }
        });

        at1.start();
        at2.start();

        at1.join();
        at2.join();

        // AtomicStampedReference

        Thread tsf1 = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    //讓 tsf2先獲取stamp，導致預期時間戳不一致
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                // 預期引用：100，更新後的引用：110，預期標識getStamp() 更新後的標識getStamp() + 1
                atomicStampedReference.compareAndSet(100,110,atomicStampedReference.getStamp(),atomicStampedReference.getStamp() + 1);
                atomicStampedReference.compareAndSet(110,100,atomicStampedReference.getStamp() + 1);
            }
        });

        Thread tsf2 = new Thread(new Runnable() {
            @Override
            public void run() {
                int stamp = atomicStampedReference.getStamp();

                try {
                    TimeUnit.SECONDS.sleep(2);      //執行緒tsf1執行完
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("AtomicStampedReference:" +atomicStampedReference.compareAndSet(100,120,stamp,stamp + 1));
            }
        });

        tsf1.start();
        tsf2.start();
    }

}
複製程式碼

執行結果：

執行結果充分展示了 AtomicInteger 導致的 ABA 問題，和使用 AtomicStampedReference 解決 ABA 問題。

相關推薦

JUC之深入分析 CAS

概述 CAS ，Compare And Swap ，即比較並交換。Doug Lea 大神在實現同步元件時，大量使用CAS 技術，鬼斧神工地實現了Java 多執行緒的併發操作。

MySql之深入分析MySql事務與鎖

MySql之深入分析MySql事務與鎖

深入分析CAS

在 Java 併發中，我們最初接觸的應該就是synchronized關鍵字，但是synchronized屬於重量級鎖，很多時候會引起效能問題，volatile也是個不錯的選擇，但是volatile不能保證原子性，只能在某些場合下使用。

【網路通訊與資訊保安】之深入分析Token、session和cookie的使用場景和區別

在Web開發領域，相信大家對於 Cookie 和 Session 都很熟悉，Cookie 和 Session 都是會話保持技術的解決方案。隨著技術的發展，Token 機制出現在我們面前，不過很多開發者對於 Token 和 Cookie、Session 的區

【死磕Java併發】—- 深入分析CAS

CAS，Compare And Swap，即比較並交換。Doug lea大神在同步元件中大量使用CAS技術鬼斧神工地實現了Java多執行緒的併發操作。整個AQS同步元件、Atomic原子類操作等等都是以CAS實現的，甚至ConcurrentHashMap在1.8的版

深入分析Java併發程式設計之CAS

在Java併發程式設計的世界裡，synchronized 和 Lock 是控制多執行緒併發環境下對共享資源同步訪問的兩大手段。其中 Lock 是 JDK 層面的鎖機制，是輕量級鎖，底層使用大量的自旋+CAS操作實現的。

深入分析iMatrix平臺流程引擎之業務補償

2019獨角獸企業重金招聘Python工程師標準>>> 流程屬性中的業務補償： 自己認為業務補償也是屬於事件的。

AQS原始碼深入分析之共享模式-你知道為什麼AQS中要有PROPAGATE這個狀態嗎？

本文基於JDK-8u261原始碼分析 本篇文章為AQS系列文的第二篇，前文請看：[傳送門]

架構之思-分析那些深入骨髓的設計原則

引子 遵從SOLID五大設計原則、遵從三大程式設計正規化……很多的設計原則對於像我這樣工作十幾年的人來說，已經刻到了骨髓裡。

JUC 之多執行緒鎖的 8 個問題分析

1. 程式程式碼   package com.atguigu.thread;import java.util.concurrent.TimeUnit;class Phone{ public synchronized void sendSMS() throws Exception{System.out.println(\"------sendSMS\");

分散式事務之深入理解什麼是2PC、3PC及TCC協議？

前言 在上一篇文章《教你一手如何基於RocketMQ搭建生產級訊息叢集》中給大家介紹了基於RocketMQ如何搭建生產級訊息叢集。因為本系列文章最終的目的是介紹基於RocketMQ的事物訊息來解決分散式系統中的資料一致性問題，

Mybatis之快取分析

前言 快取可以說是提升效能的標配，作業系統，cpu，各種各樣的框架我們總能看到快取的身影，當然Mybatis也不例外，Mybatis提供了強大的快取功能，分別有一級快取和二級快取，接下來我們來做一一介紹。

Mybatis之外掛分析

前言 Mybatis提供了強大的擴充套件功能，也就是Mybatis的外掛（plugins）功能；MyBatis允許你在已對映語句執行過程中的某一點進行攔截呼叫，攔截之後可以對已有方法新增一些定製化的功能，比如常見的分頁功能；試圖修

Kubernetes 核心元件之 Scheduler 分析

scheduler 的作用 將待排程的 POD (API 新建立的 POD,Controller manager 為補足副本而建立的 POD 等) 按照特定的排程演演算法和排程策略繫結(Binding) 到叢集中某個合適的NODE,上並將資訊寫入etcd 中,在排程過程中涉

[Skr Shop]購物車設計之需求分析

skr shop是一群底層碼農，由於被工作中的專案折磨的精神失常，加之由於程式設計師的自傲：別人設計的系統都是一坨shit，我的設計才是宇宙最牛逼，於是乎決定要做一個只設計不編碼的電商設計手冊。

3、深入分析JDK的安裝與配置

3、深入分析JDK的安裝與配置配置 我們在前兩篇文章中分別向大家通俗易懂的介紹了什麼是Java，以及有關Java的一些趣事，相信你已經迫不及待的想要正式學習Java了，畢竟之前的介紹只是一些概念，並沒有真的去接觸Java，

深入分析synchronized實現原理

EE30A7\">實現原理 Synchronized可以保證一個在多執行緒執行中，同一時刻只有一個方法或者程式碼塊被執行，它還可以保證共享變數的可見性和原子性

深入分析java中的System類

System是一個類，這個System類主要是一些與系統相關的屬性和方法的集合，而且其內部的方法全部是靜態的，所以我們直接使用System直接呼叫就好，比如我們常用的一個System.out.print。這篇文章我們就來分析一下System

深入分析java記憶體模型（注意和java記憶體結構的區別）

最近在更java多執行緒相關的文章，正好有人問我一些java記憶體模型的問題，因此花了一些時間，好好地瞭解一下。本篇文章主要是為瞭解決以下幾個問題？

關於MySQL死鎖問題的深入分析

前言 如果我們的業務處在一個非常初級的階段，併發程度比較低，那麼我們可以幾年都遇不到一次死鎖問題的發生，反之，我們業務的併發程度非常高，那麼時不時爆出的死鎖問題肯定讓我們非常撓頭。不過在死鎖問題發生時，