文章結構
前言
想要讀懂 Java 中的並發包，就是要先讀懂 CAS 機制，因為 CAS 是並發包的底層實現原理。本文主要討論
- CAS 是如何保證操作的原子性的
- Java8 對 CAS 進行了哪些優化
synchronized：大材小用
我們先來看幾行代碼：
public class CASTest {
static int i = 0;
public static void increment() {
i++;
}
}
假如有100個線程同時調用 increment() 方法對 i 進行自增操作，i 的結果會是 100 嗎？
學會多線程的同學應該都知道，這個方法是線程不安全的，由於 i++ 不是一個原子操作，所以是很難得到 100 的。
100個線程同時調用 increment()進行 i++ 操作，為什么得不到100？
i++操作計算機需要分成三步來執行：
- 讀取 i 的值。
- 把 i 加 1。
- 把最終 i 的結果寫入內存之中。所以，
- 假如線程 A 讀取了 i 的值為 i = 0，這個時候線程 B 也讀取了 i 的值 i = 0。
- 接着 A把 i 加 1，然后寫入內存，此時 i = 1。緊接着，B也把 i 加 1，此時線程B中的 i = 1，然后線程 B 把 i 寫入內存，此時內存中的 i = 1。
- 也就是說，線程 A, B 都對 i 進行了自增，但最終的結果卻是 1，不是 2。
解決思路一般都是給這個方法加個鎖
public class CASTest {
static int i = 0;
public synchronized static void increment() {
i++;
}
}
加了 synchronized 之后，就最多只能有一個線程能夠進入這個 increment() 方法了。這樣，就不會出現線程不安全了。不懂 synchronized 的可以看我這篇文章：徹底搞懂synchronized(從偏向鎖到重量級鎖)
然而，一個簡簡單單的自增操作，就加了 synchronized 進行同步，好像有點大材小用的感覺，加了 synchronized 關鍵詞之后，當有很多線程去競爭 increment 這個方法的時候，拿不到鎖的方法是會被阻塞在方法外面的，最后再來喚醒他們，而阻塞/喚醒這些操作，是非常消耗時間的。
CAS ：這種小事交給我
那有沒有其他方法來代替 synchronized 對方法的加鎖，並且保證 increment() 方法是線程安全呢？
大家看一下，如果我采用下面這種方式，能否保證 increment 是線程安全的呢？步驟如下：
CAS原理
- 線程從內存中讀取 i 的值，假如此時 i 的值為 0，我們把這個值稱為 k 吧，即此時 k = 0。
- 令 j = k + 1。
- 用 k 的值與內存中i的值相比，如果相等，這意味着沒有其他線程修改過 i 的值，我們就把 j（此時為1） 的值寫入內存；如果不相等（意味着i的值被其他線程修改過），我們就不把j的值寫入內存，而是重新跳回步驟 1，繼續這三個操作。
CAS原理翻譯成代碼示例
public static void increment() {
do{
int k = i;
int j = k + 1;
}while (compareAndSet(i, k, j))
}
如果你去模擬一下，就會發現，這樣寫是線程安全的。
這里可能有人會說，第三步的 compareAndSet 這個操作不僅要讀取內存，還干了比較、寫入內存等操作,這一步本身就是線程不安全的啊？
如果你能想到這個，說明你是真的有去思考、模擬這個過程，不過我想要告訴你的是，這個 compareAndSet 操作，他其實只對應操作系統的一條硬件操作指令，盡管看似有很多操作在里面，但操作系統能夠保證他是原子執行的。
對於一條英文單詞很長的指令，我們都喜歡用它的簡稱來稱呼他，所以，我們就把 compareAndSet 稱為 CAS 吧。
所以，采用 CAS 這種機制的寫法也是線程安全的，通過這種方式，可以說是不存在鎖的競爭，也不存在阻塞等事情的發生，可以讓程序執行的更好。
在 Java 中，也是提供了這種 CAS 的原子類
- AtomicBoolean
- AtomicInteger
- AtomicLong
- AtomicReference
具體如何使用呢？我就以上面那個例子進行改版吧，代碼如下：
public class CASTest {
static AtomicInteger i = new AtomicInteger(0);
public static void increment() {
// 自增 1並返回之后的結果
i.incrementAndGet();
}
}
CAS：誰偷偷更改了我的值
什么是ABA？
雖然這種 CAS 的機制能夠保證increment() 方法，但依然有一些問題，例如，當線程A即將要執行第三步的時候，線程 B 把 i 的值加1，之后又馬上把 i 的值減 1，然后，線程 A 執行第三步，這個時候線程 A 是認為並沒有人修改過 i 的值，因為 i 的值並沒有發生改變。而這，就是我們平常說的ABA問題。
對於基本類型的值來說，這種把數字改變了在改回原來的值是沒有太大影響的，但如果是對於引用類型的話，就會產生很大的影響了。
如何解決ABA？
為了解決這個 ABA 的問題，我們可以引入版本控制，例如，每次有線程修改了引用的值，就會進行版本的更新，雖然兩個線程持有相同的引用，但他們的版本不同，這樣，我們就可以預防 ABA 問題了。Java 中提供了 AtomicStampedReference 這個類，就可以進行版本控制了。
Java8 對 CAS 的優化
Java8之前CAS存在的問題
由於采用這種 CAS 機制是沒有對方法進行加鎖的，所以，所有的線程都可以進入 increment() 這個方法，假如進入這個方法的線程太多，就會出現一個問題：每次有線程要執行第三個步驟的時候，i 的值老是被修改了，所以線程又到回到第一步繼續重頭再來。
而這就會導致一個問題：由於線程太密集了，太多人想要修改 i 的值了，進而大部分人都會修改不成功，白白着在那里循環消耗資源。
Java8對CAS的優化方法
為了解決這個問題，Java8 引入了一個 cell[] 數組，它的工作機制是這樣的：
- 假如有 5 個線程要對 i 進行自增操作，由於 5 個線程的話，不是很多，起沖突的幾率較小，那就讓他們按照以往正常的那樣，采用 CAS 來自增吧。
- 如果有 100 個線程要對 i 進行自增操作的話，這個時候，沖突就會大大增加，系統就會把這些線程分配到不同的 cell 數組元素去。假如 cell[10] 有 10 個元素吧，且元素的初始化值為 0，那么系統就會把 100 個線程分成 10 組，每一組對 cell 數組其中的一個元素做自增操作，這樣到最后，cell 數組 10 個元素的值都為 10，系統在把這 10 個元素的值進行匯總，進而得到 100，二這，就等價於 100 個線程對 i 進行了 100 次自增操作。