在Java并發(fā)編程的世界里，synchronized 和 Lock 是控制多線程并發(fā)環(huán)境下對共享資源同步訪問的兩大手段。其中 Lock 是 JDK 層面的鎖機制，是輕量級鎖，底層使用大量的自旋+CAS操作實現(xiàn)的。

學(xué)習(xí)并發(fā)推薦《Java并發(fā)編程的藝術(shù)》

那什么是CAS呢？CAS，compare and swap，即比較并交換，什么是比較并交換呢？在Lock鎖的理念中，采用的是一種樂觀鎖的形式，即多線程去修改共享資源時，不是在修改之前就加鎖，而是樂觀的認為沒有別的線程和自己爭鎖，就是通過CAS的理念去保障共享資源的安全性的。CAS的基本思想是，拿變量的原值和內(nèi)存中的值進行比較，如果相同，則原值沒有被修改過，那么就將原值修改為新值，這兩步是原子的，能夠保證同一時間只有一個線程修改成功。這就是CAS的理念。

Java中要想使用CAS原子的修改某值，怎么做呢？幸運的是Java提供了這樣的API，就是在sun.misc.Unsafe.java類中。Unsafe，中文名不安全的，也被稱為魔術(shù)類，魔法類。

Unsafe類介紹

Unsafe類使Java擁有了像C語言的指針一樣操作內(nèi)存空間的能力，一旦能夠直接操作內(nèi)存，這也就意味著

（1）不受JVM管理，意思就是使用Unsafe操作內(nèi)存無法被JVM GC，需要我們手動GC，稍有不慎就會出現(xiàn)內(nèi)存泄漏。（2）Unsafe的不少方法中必須提供原始地址(內(nèi)存地址)和被替換對象的地址，并且偏移量要自己計算（其提供的有計算偏移量的方法），所以一旦出現(xiàn)問題就是JVM崩潰級別的異常，會導(dǎo)致整個JVM實例崩潰，表現(xiàn)為應(yīng)用程序直接crash掉。（3）直接操作內(nèi)存，所以速度更快，在高并發(fā)的條件之下能夠很好地提高效率。

因此，從上面三個角度來看，雖然在一定程度上提升了效率但是也帶來了指針的不安全性。這也是它被取名為Unsafe的原因吧。

下面我們深入到源碼中看看，提供了什么方法直接操作內(nèi)存。

打開Unsafe這個類，我們會發(fā)現(xiàn)里面有大量的被native關(guān)鍵字修飾的方法，這意味著這些方法是C語言提供的實現(xiàn)，底層調(diào)的是C語言的庫函數(shù)，我們無法直接看到他的源碼實現(xiàn)，需要去從OpenJDK去看了。另外還有一些基于native方法封裝的其他方法，整個Unsafe中的方法大致可以歸結(jié)為以下幾類：

（1）初始化操作（2）操作對象屬性（3）操作數(shù)組元素（4）線程掛起和恢復(fù)（5）CAS機制

CAS的使用

如果你學(xué)過java并發(fā)編程的話，稍微閱讀過JUC并發(fā)包里面的源碼的話，對這個Unsafe類一定不陌生，因為整個java并發(fā)包底層實現(xiàn)的核心就是靠它。JUC并發(fā)包中主要使用它提供的CAS（compare and swap，比較并交換）操作，原子的修改鎖的狀態(tài)和一些隊列元素。

沒看過JUC源碼的讀者也不用擔(dān)心，今天我們就是簡單介紹Unsafe類中的CAS操作，那么我們接下來就會通過一個簡單的例子來看看Unsafe的CAS是怎么使用的。

首先，使用這個類我們第一個要做的事情就是拿到這個類的實例，下面我們自定義了一個Util類用來獲取Unsafe的實例

import sun.misc.Unsafe;import java.lang.reflect.Field;public class UnsafeUtil { public static Unsafe reflectGetUnsafe() { try { Field field = Unsafe.class.getDeclaredField('theUnsafe'); field.setAccessible(true); return (Unsafe) field.get(null); } catch (Exception e) { e.printStackTrace(); } return null; }}

這個工具類通過反射的方式拿到Unsafe類中的一個名為theUnsafe字段，該字段是Unsafe類型，并在static塊中new一個Unsafe對象初始化這個字段（單例模式）。

然后我們定義了一個AtomicState類，這個類很簡單，有一個int型的state字段，還有一個Unsafe的常量，以及int型的offsetState，用來記錄state字段在AtomicState對象中的偏移量。具體代碼如下：

import com.walking.juc.util.UnsafeUtil;import sun.misc.Unsafe;public class AtomicState { private volatile int state = 0; public int getState() { return state; } private static final Unsafe UNSAFE = UnsafeUtil.reflectGetUnsafe(); private static final long offsetState; static { try { offsetState = UNSAFE.objectFieldOffset(AtomicState.class.getDeclaredField('state')); } catch (NoSuchFieldException e) { throw new Error(e); } } public final boolean compareAndSetState(int oldVal, int newVal) { return UNSAFE.compareAndSwapInt(this, offsetState, oldVal, newVal); }}

我們定義了一個compareAndSetState方法，需要傳兩個參數(shù)，分別是state的舊值和新值，也就是讀到的state的之前的值，以及想要把它修改成什么值，該方法內(nèi)部調(diào)用的是Unsafe類的compareAndSwapInt方法，它有四個參數(shù)，分別是要修改的類實例對象、要修改的值的偏移量、舊值、新值。解釋一下偏移量，剛才我們提到Unsafe提供給我們直接訪問內(nèi)存的能力，那么訪問內(nèi)存肯定是要知道內(nèi)存的地址在哪才能去修改其相應(yīng)的值吧，我們看，第一個參數(shù)是對象實例引用，也就是說，已經(jīng)知道這個對象的地址了，那么我們想修改這個對象里的state的值，就只需要計算出state在這個對象的偏移量就能找到state所在的內(nèi)存地址，那就可以修改它了。

然后，我們通過一個測試類來驗證Unsafe的CAS操作。這個測試類我來解釋下大致的思想，我們弄5個線程，讓這個5個線程一個個啟動，我們無法保證線程同時開始啟動，那么我們有辦法保證這個5個線程同時執(zhí)行我們的代碼，就是使用JUC包里的CyclicBarrier工具來實現(xiàn)的，這個工具初始化時需要傳入一個int值n，我們在線程的run方法內(nèi)部在業(yè)務(wù)代碼執(zhí)行之前調(diào)用CyclicBarrier的await方法，當指定數(shù)量n的線程都調(diào)用了這個方法那么這n個線程將同時往下執(zhí)行，就像設(shè)置了一個屏障，所有人都達到這個屏障后，一起通過屏障，依次來模擬多線程并發(fā)

import lombok.extern.slf4j.Slf4j;import java.util.concurrent.BrokenBarrierException;import java.util.concurrent.CountDownLatch;import java.util.concurrent.CyclicBarrier;@Slf4jpublic class TestAtomicState { static int tNum = 5;//線程數(shù) 我們開10個線程模擬多線程并發(fā) static CyclicBarrier cyclicBarrier = new CyclicBarrier(tNum);//柵欄 static CountDownLatch countDownLatch = new CountDownLatch(tNum);//計數(shù)器 static AtomicState atomicState = new AtomicState(); public static void main(String[] args) throws InterruptedException { for (int i = 1; i <= tNum; i++) { new Thread(new MyTask(),'t-'+i).start(); } countDownLatch.await();//為的是讓主線程在這句阻塞住，等待所有線程執(zhí)行完畢(計數(shù)器減到0)再往下走 log.info('state最后的值:' + atomicState.getState()); } static class MyTask implements Runnable{ @Override public void run() { try { log.info(Thread.currentThread().getName() + '到達起跑線'); String name = Thread.currentThread().getName(); String substring = name.substring(name.indexOf('-') + 1); int i1 = Integer.parseInt(substring); cyclicBarrier.await();//設(shè)置一個屏障，所有線程達到這后開始一起往下執(zhí)行 模擬并發(fā) boolean b = atomicState.compareAndSetState(0, i1); if (b) { log.info('修改成功，tName:{}' ,Thread.currentThread().getName()); } else { log.info('修改失敗，tName:{}' ,Thread.currentThread().getName()); } } catch (InterruptedException | BrokenBarrierException e) { e.printStackTrace(); } finally { countDownLatch.countDown();//線程執(zhí)行完畢計數(shù)器減一 } } }}

在cyclicBarrier.await();之后我們調(diào)用AtomicState的compareAndSetState方法傳入舊值0和新值，新值就是線程名t-n中的n，哪個線程修改成功，最后state值就是線程名中的數(shù)字。至于CountDownLatch使用它的目的是讓mian線程等到t-1到t-5的線程全部執(zhí)行完后打印state的值。我們的重點不是CyclicBarrier和CountDownLatch，知道它們是干什么的就行。

然后我們運行這個測試程序：

13:57:46.619 [t-2] INFO com.walking.castest.TestAtomicState - t-2到達起跑線13:57:46.619 [t-3] INFO com.walking.castest.TestAtomicState - t-3到達起跑線13:57:46.619 [t-5] INFO com.walking.castest.TestAtomicState - t-5到達起跑線13:57:46.619 [t-1] INFO com.walking.castest.TestAtomicState - t-1到達起跑線13:57:46.619 [t-4] INFO com.walking.castest.TestAtomicState - t-4到達起跑線13:57:46.628 [t-1] INFO com.walking.castest.TestAtomicState - 修改失敗，tName:t-113:57:46.628 [t-4] INFO com.walking.castest.TestAtomicState - 修改成功，tName:t-413:57:46.628 [t-2] INFO com.walking.castest.TestAtomicState - 修改失敗，tName:t-213:57:46.628 [t-5] INFO com.walking.castest.TestAtomicState - 修改失敗，tName:t-513:57:46.628 [t-3] INFO com.walking.castest.TestAtomicState - 修改失敗，tName:t-313:57:46.636 [main] INFO com.walking.castest.TestAtomicState - state最后的值:4

可以看到只有一個線程執(zhí)行成功，這就是CAS的基本使用。

CAS的ABA問題

何為ABA問題呢？舉個例子，小明和小花合伙賣煎餅，不就后攢了10萬元，他們一起去銀行把錢存在他們公共的賬戶里，但是小明聽說最近牛市來了，就偷偷的把錢轉(zhuǎn)移到了股票市場，公共賬戶余額是0。1個月后股票賺了一筆錢，然后小明把之前轉(zhuǎn)移的10萬元又存到他們的公共賬戶。小明和小花一個月后又去存錢，去查賬戶余額是10萬。這就是ABA問題，簡單來說就是一個值本來是A，兩個線程同時都看到是A，然后線程1把A改成B后又改成A，線程1結(jié)束了。然后線程2去修改時，看到的是A，無法感知到這個過程中值發(fā)生過變化，對于線程2來說就發(fā)生了ABA的問題。

模擬ABA問題：

import java.util.concurrent.atomic.AtomicInteger;@Slf4jpublic class CAS_ABA_Stampe { static AtomicInteger atomicInteger = new AtomicInteger(10); public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { try { log.info('{}拿到state的值為:{}', Thread.currentThread().getName(), atomicInteger.get()); log.info('{}第一次修改', Thread.currentThread().getName()); atomicInteger.getAndSet(0); Thread.sleep(2000); log.info('{}第二次修改', Thread.currentThread().getName()); atomicInteger.getAndSet(10); } catch (InterruptedException e) { e.printStackTrace(); } }, 't1'); t1.start(); Thread t2 = new Thread(() -> { try { log.info('{}第一次拿到state的值為:{}', Thread.currentThread().getName(), atomicInteger.get()); Thread.sleep(2500); log.info('{}第二次拿到state的值為:{}', Thread.currentThread().getName(), atomicInteger.get()); log.info('{}開始修改state的值為2', Thread.currentThread().getName()); atomicInteger.getAndSet(20); log.info('{}修改成功', Thread.currentThread().getName()); } catch (InterruptedException e) { e.printStackTrace(); } }, 't2'); t2.start(); t1.join(); t2.join(); log.info('最終state的值:{}', atomicInteger.get()); }}

//結(jié)果t2也能修改成功，并沒有發(fā)現(xiàn)這種變化15:12:35.999 [t1] INFO com.walking.castest.CAS_ABA_Stampe - t1拿到state的值為:1015:12:35.999 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2第一次拿到state的值為:1015:12:36.014 [t1] INFO com.walking.castest.CAS_ABA_Stampe - t1第一次修改15:12:38.015 [t1] INFO com.walking.castest.CAS_ABA_Stampe - t1第二次修改15:12:38.515 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2第二次拿到state的值為:1015:12:38.515 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2開始修改state的值為215:12:38.516 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2修改成功15:12:38.516 [main] INFO com.walking.castest.CAS_ABA_Stampe - 最終state的值:20

怎么解決CAS的ABA問題呢？

那就是基于版本號去解決，增加一個版本號的概念，每次被修改這個版本號就加1，版本號是一直向前的，版本號變了，就說明被修改過。

JUC包中提供了解決ABA問題的工具：

import lombok.extern.slf4j.Slf4j;import java.util.concurrent.atomic.AtomicStampedReference;@Slf4jpublic class CAS_ABA_Stampe { static AtomicStampedReference<Integer> stampedReference = new AtomicStampedReference<>(10, 1); public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { try { int stamp = stampedReference.getStamp(); int intValue = stampedReference.getReference().intValue(); log.info('{}私挪公款拿到stamp的值為:{}，余額:{}', Thread.currentThread().getName(), stamp,intValue); stampedReference.compareAndSet(10, 0, stamp, stamp + 1); Thread.sleep(2000); stamp = stampedReference.getStamp(); intValue = stampedReference.getReference().intValue(); log.info('{}還回公款拿到stamp的值為:{}，余額:{}', Thread.currentThread().getName(), stamp,intValue); stampedReference.compareAndSet(0, 10, stamp, stamp + 1); } catch (InterruptedException e) { e.printStackTrace(); } }, 't1'); t1.start(); Thread t2 = new Thread(() -> { try { int stamp = stampedReference.getStamp(); int intValue = stampedReference.getReference().intValue(); log.info('{}拿到stamp的值為:{}，余額:{}', Thread.currentThread().getName(), stamp, intValue); Thread.sleep(3000); log.info('{}開始存款', Thread.currentThread().getName()); if (stampedReference.compareAndSet(10, 20, stamp, stamp + 1)) { log.info('{}款款成功', Thread.currentThread().getName()); }else { log.info('{}存款失敗，發(fā)現(xiàn)賬戶異常!!oldStamp:{},currentStamp:{}', Thread.currentThread().getName(),stamp,stampedReference.getStamp()); } } catch (InterruptedException e) { e.printStackTrace(); } }, 't2'); t2.start(); t1.join(); t2.join(); log.info('最終賬戶余額:{}W', stampedReference.getReference().intValue()); }}

運行結(jié)果：

15:32:37.488 [t1] INFO com.walking.castest.CAS_ABA_Stampe - t1私挪公款拿到stamp的值為:1，余額:1015:32:37.476 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2拿到stamp的值為:1，余額:1015:32:39.500 [t1] INFO com.walking.castest.CAS_ABA_Stampe - t1還回公款拿到stamp的值為:2，余額:015:32:40.498 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2開始存款15:32:40.498 [t2] INFO com.walking.castest.CAS_ABA_Stampe - t2存款失敗，發(fā)現(xiàn)賬戶異常！！oldStamp:1,currentStamp:315:32:40.498 [main] INFO com.walking.castest.CAS_ABA_Stampe - 最終賬戶余額:10W

t2存款時就發(fā)現(xiàn)賬戶異常，因為版本號已經(jīng)變成了3，和t2剛開始拿到的不一樣，說明已經(jīng)被別人修改過，從而解決ABA問題。

到這里CAS就完啦。別忘了點贊，轉(zhuǎn)發(fā)。

以上就是深入分析Java并發(fā)編程之CAS的詳細內(nèi)容，更多關(guān)于Java并發(fā)編程之CAS的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！