樂觀鎖思想在JAVA中的實現——CAS

語言: CN / TW / HK
時間 2023-02-05 20:15:04

theme: cyanosis

歡迎關注專欄【JAVA併發】

前言

生活中我們看待一個事物總有不同的態度，比如半瓶水，悲觀的人會覺得只有半瓶水了，而樂觀的人則會認為還有半瓶水呢。很多技術思想往往源於生活，因此在多個線程併發訪問數據的時候，有了悲觀鎖和樂觀鎖。

  • 悲觀鎖認為這個數據肯定會被其他線程給修改了，那我就給它上鎖，只能自己訪問，要等我訪問完，其他人才能訪問，我上鎖、解鎖都得花費我時間。
  • 樂觀鎖認為這個數據不會被修改，我就直接訪問，當我發現數據真的修改了，那我也“禮貌的”讓自己訪問失敗。

悲觀鎖和樂觀鎖其實本質都是一種思想，在JAVA中對於悲觀鎖的實現大家可能都很瞭解，可以通過synchronized、ReentrantLock加鎖實現，本文不展開講解了。那麼樂觀鎖在JAVA中是如何實現的呢？底層的實現機制又是什麼呢？

問題引入

我們用一個賬户取錢的例子來説明樂觀鎖和悲觀鎖的問題。

``` public class AccountUnsafe { // 餘額 private Integer balance;

 public AccountUnsafe(Integer balance) {
    this.balance = balance;
 }

@Override
 public Integer getBalance() {
    return balance;
 }

 @Override
 public void withdraw(Integer amount) {
    balance -= amount;
 }

} ```

  • 賬户類，withdraw()方法是取錢方法。

public static void main(String[] args) { // 賬户10000元 AccountUnsafe account = new AccountUnsafe(10000); List<Thread> ts = new ArrayList<>(); long start = System.nanoTime(); // 1000個線程，每次取10元 for (int i = 0; i < 1000; i++) { ts.add(new Thread(() -> { account.withdraw(10); })); } ts.forEach(Thread::start); ts.forEach(t -> { try { t.join(); } catch (InterruptedException e) { e.printStackTrace(); } }); long end = System.nanoTime(); // 打印賬户餘額和花費時間 log.info("賬户餘額：{}, 花費時間: {}", account.getBalance(), (end-start)/1000_000 + " ms"); }

  • 賬户默認有10000元，1000個線程取錢，每次取10元，最後賬户應該還有多少錢呢？

運行結果：

  • 運行結果顯示餘額還有150元，顯然出現併發問題。

原因分析:

原因也很簡單，取錢方法withdraw()的操作balance -= amount;看着就一行代碼，實際上會生成多條指令，如下圖所示：

多個線程運行的時候會進行線程切換，導致這個操作不是原子性，所以不是線程安全的。

悲觀鎖解決

最簡單的方法，我想大家都能想到吧，給withdraw()方法加鎖，保證同一時刻只有一個線程能夠執行這個方法，保證了原子性。

  • 通過synchronized關鍵字加鎖。

運行結果：

  • 運行結果正常，但是花費時間稍微多了一點

樂觀鎖解決

關鍵來了，如果用樂觀鎖的思想在JAVA中該如何實現呢？

大致思路就是我默認不加任何鎖，我先把餘額減掉10元，最後更新餘額的時候，發現餘額和我一開始不一樣了，我就丟棄當前更新操作，重新讀取餘額的值，直到更新成功。

找啊找，最終發現JDK中的Unsafe方法提供了這樣的方法compareAndSwapInt。

  • 先獲取老的餘額oldBalance，計算出新的餘額newBalance
  • 調用 unsafe.compareAndSwapInt()方法，如果內存中餘額屬性的偏移量BALANCE_OFFSET對應的值等於老的餘額，説明的確沒有被其他線程訪問修改過，我就大膽的更新為newBalance，退出方法
  • 否則的話，我就要進入下一次循環，重新獲取餘額計算。

那麼是如何獲取unsafe呢?

  • 靜態方法中通過反射的方法獲取，因為Unsafe類太底層了，它一般不建議程序員直接使用。

這個Unsafe類的名稱並不是説線程不安全的意思，只是這個類太底層了，不要亂用，對程序員來説不大安全。

最後別忘了餘額balance要加volatile修飾。

  • 主要為了保證可見性，讓線程能夠獲取到其他線程修改的結果。

運行結果：

  • 餘額也為0，正常，而且運行速度稍微快了一丟丟

完成代碼：

``` @Slf4j(topic = "a.AccountCAS") public class AccountCAS { // 餘額 private volatile int balance; // Unsafe對象 static final Unsafe unsafe; // balance 字段的偏移量 static final long BALANCE_OFFSET; static { try { Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe"); theUnsafe.setAccessible(true); unsafe = (Unsafe) theUnsafe.get(null); // balance 屬性在 AccountCAS 對象中的偏移量，用於 Unsafe 直接訪問該屬性 BALANCE_OFFSET = unsafe.objectFieldOffset(AccountCAS.class.getDeclaredField("balance")); } catch (NoSuchFieldException | IllegalAccessException e) { throw new Error(e); } }

public AccountCAS(Integer balance) {
    this.balance = balance;
}

public int getBalance() {
    return balance;
}

public void withdraw(Integer amount) {
    // 自旋
    while (true) {
        // 獲取老的餘額
        int oldBalance = balance;
        // 獲取新的餘額
        int newBalance = oldBalance - amount;
        // 更新餘額，BALANCE_OFFSET表示balance屬性的偏移量， 返回true表示更新成功， false更新失敗，繼續更新
        if(unsafe.compareAndSwapInt(this, BALANCE_OFFSET, oldBalance, newBalance)) {
            return;
        }
    }
}

public static void main(String[] args) {
    // 賬户10000元
    AccountCAS account = new AccountCAS(10000);
    List<Thread> ts = new ArrayList<>();
    long start = System.nanoTime();
    // 1000個線程，每次取10元
    for (int i = 0; i < 1000; i++) {
        ts.add(new Thread(() -> {
            account.withdraw(10);
        }));
    }
    ts.forEach(Thread::start);
    ts.forEach(t -> {
        try {
            t.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
    long end = System.nanoTime();
    // 打印賬户餘額和花費時間
    log.info("賬户餘額：{}, 花費時間: {}", account.getBalance(), (end-start)/1000_000 + " ms");
}

} ```

樂觀鎖改進

好麻煩呀，我們自己調用原生的UnSafe類實現樂觀鎖，有什麼更好的方式嗎？

當然有，其實JDK給我們封裝了很多基於UnSafe樂觀鎖實現的原子類，比如AtomicInteger、AtomicReference等等。我們用AtomicInteger改寫下上面的實現。

  • 使用JDK中的原子類AtomicInteger作為餘額的類型
  • 取錢邏輯直接調用addAndGet方法

運行結果：

原理：

查看源碼最終也是調用的Unsafe方法。

CAS機制

前面的一個取錢的例子，大家是不是對樂觀鎖的思想以及在JAVA中的實現更深入的認識。

在JAVA中對這種實現起了一個名字，叫做CAS, 全稱Compare And Swap，是不是很形象，先比較，然後再替換。

那CAS的本質是什麼？

CAS先比較然後再替換，感覺是有2步，比較和替換，不像是原子性操作，如果不是原子性操作問題就可大了。實際上，CAS本質對應的是一條指令，是原子操作。

CAS 的底層是 lock cmpxchg 指令（X86 架構），在單核 CPU 和多核 CPU 下都能夠保證【比較-交換】的原子性。

強調一點，CAS 必須藉助 volatile 才能讀取到共享變量的最新值來實現【比較並交換】的效果，因為volatile會保證變量的可見性。

總結

結合 CAS 和 volatile 可以實現無鎖併發，適用於線程數少、多核 CPU 的場景或者讀多寫少的場景。

  • CAS 是基於樂觀鎖的思想：最樂觀的估計，不怕別的線程來修改共享變量，就算改了也沒關係，我吃虧點再重試唄。
  • synchronized 是基於悲觀鎖的思想：最悲觀的估計，得防着其它線程來修改共享變量，我上了鎖你們都別想改，我改完了解開鎖，你們才有機會。
  • CAS 體現的是無鎖併發、無阻塞併發，請仔細體會這兩句話的意思
    • 因為沒有使用 synchronized，所以線程不會陷入阻塞，這是效率提升的因素之一
    • 但如果競爭激烈，可以想到重試必然頻繁發生，反而效率會受影響

如果本文對你有幫助的話，請留下一個贊吧

本文正在參加「金石計劃 . 瓜分6萬現金大獎」

「」
「」