Java 併發程式設計的可見性、有序性和原子性
併發程式設計無論在哪門語言裡，都屬於高階篇，面試中也嚐嚐會被問到。想要深入理解併發程式設計機制確實不是一件容易的事，因為它涉及到計算機底層和作業系統的相關知識，如果對這部分知識不是很清楚可能會導致理解困難。
在這個專欄裡，王子會盡量以白話和圖片的方式剖析併發程式設計本質，希望可以讓大家更容易理解。
今天我們就來談一談可見性、有序性和原子性都是什麼東西。
併發程式設計的幕後
進入主題之前，我們先來了解一下併發程式設計的幕後。
隨著CPU、記憶體和I/O裝置的不斷升級，它們之間一直存在著一個矛盾，就是速度不一致問題。CPU的速度高於記憶體，記憶體的速度又高於I/O裝置。
我們寫的程式碼中大多數內容都會經過記憶體處理，有些內容會去讀寫I/O裝置，根據木桶理論，整體的效能取決於最慢的操作，就是I/O裝置，所以單單提升CPU的效能是不夠的。
為了最大化體現出CPU的效能，計算機底層主要做了三部分優化：
1.CPU增加了快取，比記憶體速度更快，平衡記憶體的速度
2.作業系統增加了程序和執行緒，可以對CPU分時複用
3.編譯程式會進行指令的重排，使快取更好的發揮性能
我們平時的工作中其實一直都享受著這些優化後的成果，但同時他們也會導致一些很難找到原因的BUG。
什麼是可見性
首先我們就來看看什麼是可見性。
一個執行緒對共享變數的修改，另一個執行緒可以感知到，我們稱其為可見性。
在單核時代，其實是不存在可見性問題的，因為所有的執行緒都是在一個CPU中工作的，一個執行緒的寫操作對於其他的執行緒一定是可見的。
但是多核CPU出現後，每個CPU都有自己的快取，多個執行緒在不同的CPU中處理資料就會導致不可見問題。
假設變數v的值是1， 兩個執行緒同時執行了v++操作，首先會從記憶體中讀取變數v的資料到各自的CPU快取中，這個時候兩個CPU快取中的v都是1，執行v++後，兩個變數v都變成了2，然後再寫回記憶體，記憶體中的變數v就變成了2。
但其實我們想看到的結果v最終應該是3才對。
在CPU1快取中執行v++後，CPU2快取無法感知的到，這就是可見性問題。而由於可見性問題導致的最終資料不正確，就是執行緒安全問題。
什麼是原子性
由於I/O的速度太慢，早期的作業系統發明了多程序，就是允許某個程序執行一小段時間後，重新選擇一個程序來執行，這個過程叫做任務切換，而這一小段的時間我們稱其為時間片。
現在作業系統的任務切換一般指的是更輕量級的執行緒切換，java的併發程式設計是基於多執行緒的，自然也會存線上程切換。
一般會在時間片結束的時候進行執行緒切換，java語言中執行的一段簡單的程式碼往往需要多條CPU的指令實現，比如count++這部分程式碼，至少需要三條CPU指令：
1.首先把count從記憶體中讀取到CPU的暫存器中
2.在暫存器中執行+1操作
3.最後將count的值寫入記憶體中（可能寫入到CPU的快取中）
而執行緒切換是可以發生在任意的一條CPU指令執行之後的，注意，這裡說的是CPU的指令，而不是java語言中的指令，對於上面的三條指令來說，我們假設 count=0，如果執行緒 A 在指令 1 執行完後做執行緒切換，執行緒 A 和執行緒 B 按照下圖的順序執行，那麼我們會發現兩個執行緒都執行了 count++ 的操作，但是得到的結果不是我們期望的 2，而是 1。
這就是執行緒切換導致的資料錯誤問題，我們把一個或者多個操作在 CPU 執行的過程中不被中斷的特性稱為原子性，CPU 能保證的原子操作是 CPU 指令級別的，而不是高階語言的操作符，這是違揹我們直覺的地方。因此，很多時候我們需要在高階語言層面保證操作的原子性。
什麼是有序性
有序性指的是程式按照程式碼的先後順序執行。編譯器為了優化效能，有時候會改變程式中語句的先後順序，例如程式中：“x=1；y=2；”編譯器優化後可能變成“y=2；x=1；”。
在這個例子中，編譯器調整了語句的順序，但是不影響程式的最終結果。不過有時候調整了語句的順序可能導致意想不到的 Bug。
在 Java 領域一個經典的案例就是利用雙重檢查建立單例物件，程式碼如下：
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
假設有兩個執行緒 A、B 同時呼叫 getInstance() 方法，他們會同時發現instance == null，於是同時對 Singleton.class 加鎖，此時 JVM 保證只有一個執行緒能夠加鎖成功（假設是執行緒 A），另外一個執行緒則會處於等待狀態（假設是執行緒 B）；執行緒 A 會建立一個 Singleton 例項，之後釋放鎖，鎖釋放後，執行緒 B 被喚醒，執行緒 B 再次嘗試加鎖，此時是可以加鎖成功的，加鎖成功後，執行緒 B 檢查instance == null時會發現，已經建立過 Singleton 例項了，所以執行緒 B 不會再建立一個 Singleton 例項。
這個過程看上去是不是無懈可擊，沒有漏洞？
答案是否定的，問題就出在了new操作上，我們以為的new操作是這樣的：
1.分配一塊記憶體空間
2.在這塊記憶體空間上初始化Singleton例項物件
3.把這個物件的記憶體地址賦值給instance變數
但實際上由於指令重排，優化後的過程是這樣的：
1.分配一塊記憶體空間
2.把這快記憶體空間的記憶體地址賦值給instance變數
3.在這塊記憶體空間上初始化Singleton例項物件
那麼這樣調換順序後會發生什麼呢？
我們假設執行緒 A 先執行 getInstance() 方法，當執行完指令 2 時恰好發生了執行緒切換，切換到了執行緒 B 上；如果此時執行緒 B 也執行 getInstance() 方法，那麼執行緒 B 在執行第一個判斷時會發現instance != null，所以直接返回 instance，而此時的 instance 是沒有初始化過的，如果我們這個時候訪問 instance 的成員變數就可能觸發空指標異常。
總結
使用併發程式設計開發，往往會出現很多難以找到原因的BUG，通過對可見性、有序性和原子性的分析，可以為我們排查併發導致的BUG提供一些思路。
CPU快取會導致可見性
指令重排會導致有序性
執行緒切換會導致原子性
以上就是本篇文章的三個核心內容，那我們下篇文章繼續。
以上就是Java 併發程式設計的可見性、有序性和原子性的詳細內容，更多關於Java 併發程式設計的資料請關注我們其它相關文章！