- volatile和原子類
- 原子類和 volatile 的使用場景
- 總結
volatile和原子類
我們首先看一個案例。如圖所示，我們有兩個線程。
在圖中左上角可以看出，有一個公共的 boolean flag 標記位，最開始賦值爲 true。
然後線程 2 會進入一個 while 循環，並且根據這個 flag 也就是標記位的值來決定是否繼續執行或着退出。
最開始由於 flag 的值是 true，所以首先會在這裏執行一定時期的循環。然後假設在某一時刻，線程 1 把這個 flag 的值改爲 false 了，它所希望的是，線程 2 看到這個變化後停止運行。
但是這樣做其實是有風險的，線程 2 可能並不能立刻停下來，也有可能過一段時間纔會停止，甚至在最極端的情況下可能永遠都不會停止。
爲了理解發生這種情況的原因，我們首先來看一下 CPU 的內存結構，這裏是一個雙核的 CPU 的簡單示意圖：
可以看出，線程 1 和線程 2 分別在不同的 CPU 核心上運行，每一個核心都有自己的本地內存，並且在下方也有它們共享的內存。
最開始它們都可以讀取到 flag 爲 true ，不過當線程 1 這個值改爲 false 之後，線程 2 並不能及時看到這次修改，因爲線程 2 不能直接訪問線程 1 的本地內存，這樣的問題就是一個非常典型的可見性問題。
[圖片上傳失敗...(image-ba7a99-1612505968523)]
要想解決這個問題，我們只需要在變量的前面加上 volatile 關鍵字修飾，只要我們加上這個關鍵字，那麼每一次變量被修改的時候，其他線程對此都可見，這樣一旦線程 1 改變了這個值，那麼線程 2 就可以立刻看到，因此就可以退出 while 循環了。
之所以加了關鍵字之後就就可以讓它擁有可見性，原因在於有了這個關鍵字之後，線程 1 的更改會被 flush 到共享內存中，然後又會被 refresh 到線程 2 的本地內存中，這樣線程 2 就能感受到這個變化了，所以 volatile 這個關鍵字最主要是用來解決可見性問題的，可以一定程度上保證線程安全。
現在讓我們回顧一下很熟悉的多線程同時進行 value++ 的場景，如圖所示：
[圖片上傳失敗...(image-e4bd23-1612505968523)]
如果它被初始化爲每個線程都加 1000 次，最終的結果很可能不是 2000。由於 value++ 不是原子的，所以在多線程的情況下，會出現線程安全問題。但是如果我們在這裏使用 volatile 關鍵字，能不能解決問題呢?
很遺憾，即便使用了 volatile 也是不能保證線程安全的，因爲這裏的問題不單單是可見性問題，還包含原子性問題。
我們有多種辦法可以解決這裏的問題，第 1 種是使用synchronized 關鍵字，如圖所示：
這樣一來，兩個線程就不能同時去更改 value 的數值，保證了 value++ 語句的原子性，並且 synchronized 同樣保證了可見性，也就是說，當第 1 個線程修改了 value 值之後，第 2 個線程可以立刻看見本次修改的結果。
解決這個問題的第 2 個方法，就是使用我們的原子類，如圖所示：
比如用一個 AtomicInteger，然後每個線程都調用它的 incrementAndGet 方法。
在利用了原子變量之後就無需加鎖，我們可以使用它的 incrementAndGet 方法，這個操作底層由 CPU 指令保證原子性，所以即便是多個線程同時運行，也不會發生線程安全問題。
原子類和 volatile 的使用場景
我們可以看出，volatile 和原子類的使用場景是不一樣的，如果我們有一個可見性問題，那麼可以使用 volatile 關鍵字，但如果我們的問題是一個組合操作，需要用同步來解決原子性問題的話，那麼可以使用原子變量，而不能使用 volatile 關鍵字。
通常情況下，volatile 可以用來修飾 boolean 類型的標記位，因爲對於標記位來講，直接的賦值操作本身就是具備原子性的，再加上 volatile 保證了可見性，那麼就是線程安全的了。
總結
對於會被多個線程同時操作的計數器 Counter 的場景，這種場景的一個典型特點就是，它不僅僅是一個簡單的賦值操作，而是需要先讀取當前的值，然後在此基礎上進行一定的修改，再把它給賦值回去。這樣一來，我們的 volatile 就不足以保證這種情況的線程安全了。我們需要使用原子類來保證線程安全。