Java編程cas操作全面解析

CAS 指的是現(xiàn)代 CPU 廣泛支持的一種對(duì)內(nèi)存中的共享數(shù)據(jù)進(jìn)行操作的一種特殊指令。這個(gè)指令會(huì)對(duì)內(nèi)存中的共享數(shù)據(jù)做原子的讀寫操作。

簡單介紹一下這個(gè)指令的操作過程：首先，CPU 會(huì)將內(nèi)存中將要被更改的數(shù)據(jù)與期望的值做比較。然后，當(dāng)這兩個(gè)值相等時(shí)，CPU 才會(huì)將內(nèi)存中的數(shù)值替換為新的值。否則便不做操作。最后，CPU 會(huì)將舊的數(shù)值返回。這一系列的操作是原子的。它們雖然看似復(fù)雜，但卻是 Java 5 并發(fā)機(jī)制優(yōu)于原有鎖機(jī)制的根本。簡單來說，CAS 的含義是“我認(rèn)為原有的值應(yīng)該是什么，如果是，則將原有的值更新為新值，否則不做修改，并告訴我原來的值是多少”。（這段描述引自《Java并發(fā)編程實(shí)踐》）

簡單的來說，CAS有3個(gè)操作數(shù)，內(nèi)存值V，舊的預(yù)期值A(chǔ)，要修改的新值B。當(dāng)且僅當(dāng)預(yù)期值A(chǔ)和內(nèi)存值V相同時(shí)，將內(nèi)存值V修改為B，否則返回V。這是一種樂觀鎖的思路，它相信在它修改之前，沒有其它線程去修改它；而Synchronized是一種悲觀鎖，它認(rèn)為在它修改之前，一定會(huì)有其它線程去修改它，悲觀鎖效率很低。

下面看一個(gè)簡單的例子：

if(a==b) { 
  a++; 
} 

試想一下如果在做a++之前a的值被改變了怎么辦？a++還執(zhí)行嗎？出現(xiàn)該問題的原因是在多線程環(huán)境下，a的值處于一種不定的狀態(tài)。采用鎖可以解決此類問題，但CAS也可以解決，而且可以不加鎖。

int expect = a; 
if(a.compareAndSet(expect,a+1)) { 
  doSomeThing1(); 
} else { 
  doSomeThing2(); 
} 

這樣如果a的值被改變了a++就不會(huì)被執(zhí)行。

按照上面的寫法，a!=expect之后,a++就不會(huì)被執(zhí)行，如果我們還是想執(zhí)行a++操作怎么辦，沒關(guān)系，可以采用while循環(huán)

while(true) { 
  int expect = a; 
  if (a.compareAndSet(expect, a + 1)) { 
    doSomeThing1(); 
    return; 
  } else { 
    doSomeThing2(); 
  } 
} 

采用上面的寫法，在沒有鎖的情況下實(shí)現(xiàn)了a++操作，這實(shí)際上是一種非阻塞算法。

應(yīng)用

java.util.concurrent.atomic包中幾乎大部分類都采用了CAS操作，以AtomicInteger為例，看看它幾個(gè)主要方法的實(shí)現(xiàn)：

public final int getAndSet(int newValue) { 
  for (;;) { 
    int current = get(); 
    if (compareAndSet(current, newValue)) 
      return current; 
  } 
} 

getAndSet方法JDK文檔中的解釋是：以原子方式設(shè)置為給定值，并返回舊值。原子方式體現(xiàn)在何處，就體現(xiàn)在compareAndSet上，看看compareAndSet是如何實(shí)現(xiàn)的：

public final boolean compareAndSet(int expect, int update) { 
  return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 
} 

不出所料，它就是采用的Unsafe類的CAS操作完成的。

再來看看a++操作是如何實(shí)現(xiàn)的：

public final int getAndIncrement() { 
  for (;;) { 
    int current = get(); 
    int next = current + 1; 
    if (compareAndSet(current, next)) 
      return current; 
  } 
} 

幾乎和最開始的實(shí)例一模一樣，也是采用CAS操作來實(shí)現(xiàn)自增操作的。

++a操作和a++操作類似，只不過返回結(jié)果不同罷了

public final int incrementAndGet() { 
  for (;;) { 
    int current = get(); 
    int next = current + 1; 
    if (compareAndSet(current, next)) 
      return next; 
  } 
} 

此外，java.util.concurrent.ConcurrentLinkedQueue類全是采用的非阻塞算法，里面沒有使用任何鎖，全是基于CAS操作實(shí)現(xiàn)的。CAS操作可以說是JAVA并發(fā)框架的基礎(chǔ)，整個(gè)框架的設(shè)計(jì)都是基于CAS操作的。

缺點(diǎn)：

1、ABA問題

維基百科上給了一個(gè)活生生的例子——

你拿著一個(gè)裝滿錢的手提箱在飛機(jī)場(chǎng)，此時(shí)過來了一個(gè)火辣性感的美女，然后她很暖昧地挑逗著你，并趁你不注意的時(shí)候，把用一個(gè)一模一樣的手提箱和你那裝滿錢的箱子調(diào)了個(gè)包，然后就離開了，你看到你的手提箱還在那，于是就提著手提箱去趕飛機(jī)去了。

這就是ABA的問題。

CAS操作容易導(dǎo)致ABA問題,也就是在做a++之間，a可能被多個(gè)線程修改過了，只不過回到了最初的值，這時(shí)CAS會(huì)認(rèn)為a的值沒有變。a在外面逛了一圈回來，你能保證它沒有做任何壞事，不能！！也許它討閑，把b的值減了一下，把c的值加了一下等等，更有甚者如果a是一個(gè)對(duì)象，這個(gè)對(duì)象有可能是新創(chuàng)建出來的，a是一個(gè)引用呢情況又如何，所以這里面還是存在著很多問題的，解決ABA問題的方法有很多，可以考慮增加一個(gè)修改計(jì)數(shù)，只有修改計(jì)數(shù)不變的且a值不變的情況下才做a++，也可以考慮引入版本號(hào)，當(dāng)版本號(hào)相同時(shí)才做a++操作等，這和事務(wù)原子性處理有點(diǎn)類似！

2、比較花費(fèi)CPU資源，即使沒有任何爭(zhēng)用也會(huì)做一些無用功。

3、會(huì)增加程序測(cè)試的復(fù)雜度，稍不注意就會(huì)出現(xiàn)問題。

總結(jié)

可以用CAS在無鎖的情況下實(shí)現(xiàn)原子操作，但要明確應(yīng)用場(chǎng)合，非常簡單的操作且又不想引入鎖可以考慮使用CAS操作，當(dāng)想要非阻塞地完成某一操作也可以考慮CAS。不推薦在復(fù)雜操作中引入CAS，會(huì)使程序可讀性變差，且難以測(cè)試，同時(shí)會(huì)出現(xiàn)ABA問題。

以上是本文關(guān)于Java編程cas操作的全部內(nèi)容，希望對(duì)大家能有所幫助。