簡介

CAS的原理其實(shí)很簡單，為了保證在多線程環(huán)境下我們的更新是符合預(yù)期的，或者說一個(gè)線程在更新某個(gè)對象的時(shí)候，沒有其他的線程對該對象進(jìn)行修改。在線程更新某個(gè)對象（或值）之前，先保存更新前的值，然后在實(shí)際更新的時(shí)候傳入之前保存的值，進(jìn)行比較，如果一致的話就進(jìn)行更新，否則失敗。

注意，CAS在java中是用native方法來實(shí)現(xiàn)的，利用了系統(tǒng)本身提供的原子性操作。

那么CAS在使用中會有什么問題呢？一般來說CAS如果設(shè)計(jì)的不夠完美的話，可能會產(chǎn)生ABA問題，而ABA問題又可以分為兩類，我們先看來看一類問題。

第一類問題

我們考慮下面一種ABA的情況：

1.在多線程的環(huán)境中，線程a從共享的地址X中讀取到了對象A。

2.在線程a準(zhǔn)備對地址X進(jìn)行更新之前，線程b將地址X中的值修改為了B。

3.接著線程b將地址X中的值又修改回了A。

4.最新線程a對地址X執(zhí)行CAS，發(fā)現(xiàn)X中存儲的還是對象A，對象匹配，CAS成功。

上面的例子中CAS成功了，但是實(shí)際上這個(gè)CAS并不是原子操作，如果我們想要依賴CAS來實(shí)現(xiàn)原子操作的話可能就會出現(xiàn)隱藏的bug。

第一類問題的關(guān)鍵就在2和3兩步。這兩步我們可以看到線程b直接替換了內(nèi)存地址X中的內(nèi)容。

在擁有自動(dòng)GC環(huán)境的編程語言，比如說java中，2，3的情況是不可能出現(xiàn)的，因?yàn)樵趈ava中，只要兩個(gè)對象的地址一致，就表示這兩個(gè)對象是相等的。

2，3兩步可能出現(xiàn)的情況就在像C++這種，不存在自動(dòng)GC環(huán)境的編程語言中。因?yàn)榭梢宰约嚎刂茖ο蟮纳芷?，如果我們從一個(gè)list中刪除掉了一個(gè)對象，然后又重新分配了一個(gè)對象，并將其add back到list中去，那么根據(jù) MRU memory allocation算法，這個(gè)新的對象很有可能和之前刪除對象的內(nèi)存地址是一樣的。這樣就會導(dǎo)致ABA的問題。

第二類問題

如果我們在擁有自動(dòng)GC的編程語言中，那么是否仍然存在CAS問題呢？

考慮下面的情況，有一個(gè)鏈表里面的數(shù)據(jù)是A->B->C,我們希望執(zhí)行一個(gè)CAS操作，將A替換成D，生成鏈表D->B->C。考慮下面的步驟：

1.線程a讀取鏈表頭部節(jié)點(diǎn)A。

2.線程b將鏈表中的B節(jié)點(diǎn)刪掉，鏈表變成了A->C

3.線程a執(zhí)行CAS操作，將A替換從D。

最后我們的到的鏈表是D->C，而不是D->B->C。

問題出在哪呢？CAS比較的節(jié)點(diǎn)A和最新的頭部節(jié)點(diǎn)是不是同一個(gè)節(jié)點(diǎn)，它并沒有關(guān)心節(jié)點(diǎn)A在步驟1和3之間是否內(nèi)容發(fā)生變化。

我們舉個(gè)例子：

public void useABAReference(){
    CustUser a= new CustUser();
    CustUser b= new CustUser();
    CustUser c= new CustUser();
    AtomicReference<CustUser> atomicReference= new AtomicReference<>(a);
    log.info("{}",atomicReference.compareAndSet(a,b));
    log.info("{}",atomicReference.compareAndSet(b,a));
    a.setName("change for new name");
    log.info("{}",atomicReference.compareAndSet(a,c));
}

上面的例子中，我們使用了AtomicReference的CAS方法來判斷對象是否發(fā)生變化。在CAS b和a之后，我們將a的name進(jìn)行了修改，我們看下最后的輸出結(jié)果：

[main] INFO com.flydean.aba.ABAUsage - true

[main] INFO com.flydean.aba.ABAUsage - true

[main] INFO com.flydean.aba.ABAUsage - true

三個(gè)CAS的結(jié)果都是true。說明CAS確實(shí)比較的兩者是否為統(tǒng)一對象，對其中內(nèi)容的變化并不關(guān)心。

第二類問題可能會導(dǎo)致某些集合類的操作并不是原子性的，因?yàn)槟悴⒉荒鼙ＷC在CAS的過程中，有沒有其他的節(jié)點(diǎn)發(fā)送變化。

第一類問題的解決

第一類問題在存在自動(dòng)GC的編程語言中是不存在的，我們主要看下怎么在C++之類的語言中解決這個(gè)問題。

根據(jù)官方的說法，第一類問題大概有四種解法：

1.使用中間節(jié)點(diǎn) - 使用一些不代表任何數(shù)據(jù)的中間節(jié)點(diǎn)來表示某些節(jié)點(diǎn)是標(biāo)記被刪除的。

2.使用自動(dòng)GC。

3.使用hazard pointers - hazard pointers 保存了當(dāng)前線程正在訪問的節(jié)點(diǎn)的地址，在這些hazard pointers中的節(jié)點(diǎn)不能夠被修改和刪除。

4.使用read-copy update (RCU) - 在每次更新的之前，都做一份拷貝，每次更新的是拷貝出來的新結(jié)構(gòu)。

第二類問題的解決

第二類問題其實(shí)算是整體集合對象的CAS問題了。一個(gè)簡單的解決辦法就是每次做CAS更新的時(shí)候再添加一個(gè)版本號。如果版本號不是預(yù)期的版本，就說明有其他的線程更新了集合中的某些節(jié)點(diǎn)，這次CAS是失敗的。

我們舉個(gè)AtomicStampedReference的例子：

public void useABAStampReference(){
    Object a= new Object();
    Object b= new Object();
    Object c= new Object();
    AtomicStampedReference<Object> atomicStampedReference= new AtomicStampedReference(a,0);
    log.info("{}",atomicStampedReference.compareAndSet(a,b,0,1));
    log.info("{}",atomicStampedReference.compareAndSet(b,a,1,2));
    log.info("{}",atomicStampedReference.compareAndSet(a,c,0,1));
}

AtomicStampedReference的compareAndSet方法，多出了兩個(gè)參數(shù)，分別是expectedStamp和newStamp，兩個(gè)參數(shù)都是int型的，需要我們手動(dòng)傳入。

總結(jié)

ABA問題其實(shí)是由兩類問題組成的，需要我們分開來對待和解決。

以上就是分析ABA問題的本質(zhì)及其解決辦法的詳細(xì)內(nèi)容，更多關(guān)于ABA問題的本質(zhì)及其解決辦法的資料請關(guān)注腳本之家其它相關(guān)文章！