前言
今天開始，王子準備開始一個新的專欄：併發編程專欄。
併發編程無論在哪門語言裏，都屬於高級篇，面試中也嚐嚐會被問到。想要深入理解併發編程機制確實不是一件容易的事，因爲它涉及到計算機底層和操作系統的相關知識，如果對這部分知識不是很清楚可能會導致理解困難。
在這個專欄裏，王子會盡量以白話和圖片的方式剖析併發編程本質，希望可以讓大家更容易理解。
今天我們就來談一談可見性、有序性和原子性都是什麼東西。
併發編程的幕後
進入主題之前，我們先來了解一下併發編程的幕後。
隨着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緩存會導致可見性
指令重排會導致有序性
線程切換會導致原子性
以上就是本篇文章的三個核心內容，那我們下篇文章繼續。
往期文章推薦：
