如果你細心觀察的話，你會發現，不管是哪一門編程語言，并發類的知識都是在高級篇里。換句話說，這塊知識點其實對于程序員來說，是比較進階的知識。我自己這么多年學習過來，也確實覺得并發是比較難的，因為它會涉及到很多的底層知識，比如若你對操作系統相關的知識一無所知的話，那去理解一些原理就會費些力氣。
大家都知道，編寫正確的并發程序是一件極困難的事情，并發程序的 Bug 往往會詭異地出現，然后又詭異地消失，很難重現，也很難追蹤，很多時候都讓人很抓狂。但要快速而又精準地解決“并發”類的疑難雜癥，你就要理解這件事情的本質，追本溯源，深入分析這些Bug 的源頭在哪里。
那為什么并發編程容易出問題呢？它是怎么出問題的？今天我們就重點聊聊這些 Bug 的源頭。
并發程序幕后的故事
這些年，我們的 CPU、內存、I/O 設備都在不斷迭代，不斷朝著更快的方向努力。但是，在這個快速發展的過程中，有一個核心矛盾一直存在，就是這三者的速度差異。CPU 和內存的速度差異可以形象地描述為：CPU 是天上一天，內存是地上一年（假設 CPU 執行一條普通指令需要一天，那么 CPU 讀寫內存得等待一年的時間）。內存和 I/O 設備的速度差異就更大了，內存是天上一天，I/O 設備是地上十年。
程序里大部分語句都要訪問內存，有些還要訪問 I/O，根據木桶理論（一只水桶能裝多少水取決于它最短的那塊木板），程序整體的性能取決于最慢的操作——讀寫 I/O 設備，也就是說單方面提高 CPU 性能是無效的
為了合理利用 CPU 的高性能，平衡這三者的速度差異，計算機體系機構、操作系統、編譯程序都做出了貢獻，主要體現為：
- 1. CPU 增加了緩存，以均衡與內存的速度差異；
- 2. 操作系統增加了進程、線程，以分時復用 CPU，進而均衡 CPU 與 I/O 設備的速度差異；
- 3. 編譯程序優化指令執行次序，使得緩存能夠得到更加合理地利用。
現在我們幾乎所有的程序都默默地享受著這些成果，但是天下沒有免費的午餐，并發程序很多詭異問題的根源也在這里。
源頭之一：緩存導致的可見性問題
在單核時代，所有的線程都是在一顆 CPU 上執行，CPU 緩存與內存的數據一致性容易解決。因為所有線程都是操作同一個 CPU 的緩存，一個線程對緩存的寫，對另外一個線程來說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個 CPU 里面的緩存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的最新值（線程 A 寫過的值）。
CPU 緩存與內存的關系圖
一個線程對共享變量的修改，另外一個線程能夠立刻看到，我們稱為可見性。
多核時代，每顆 CPU 都有自己的緩存，這時 CPU 緩存與內存的數據一致性就沒那么容易解決了，當多個線程在不同的 CPU 上執行時，這些線程操作的是不同的 CPU 緩存。比如下圖中，線程 A 操作的是 CPU-1 上的緩存，而線程 B 操作的是 CPU-2 上的緩存，很明顯，這個時候線程 A 對變量 V 的操作對于線程 B 而言就不具備可見性了。這個就屬于硬件程序員給軟件程序員挖的“坑”。
多核 CPU 的緩存與內存關系圖
下面我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼，每執行一次add10K() 方法，都會循環 10000 次 count+=1 操作。在 calc() 方法中我們創建了兩個線程，每個線程調用一次 add10K() 方法，我們來想一想執行 calc() 方法得到的結果應該是多少呢？
public class Test {
private long count = 0;
private void add10K()
{
int idx = 0;
while ( idx++ < 10000 )
{
count += 1;
}
}
public static long calc()
{
final Test test = new Test();
// 創建兩個線程，執行 add() 操作 //
Thread th1 = new Thread( () - > {
test.add10K();
} );
Thread th2 = new Thread( () - > {
test.add10K();
} );
// 啟動兩個線程 //
th1.start();
th2.start();
// 等待兩個線程執行結束 //
th1.join();
th2.join();
return(count);
}
}
直覺告訴我們應該是 20000，因為在單線程里調用兩次 add10K() 方法，count 的值就是20000，但實際上 calc() 的執行結果是個 10000 到 20000 之間的隨機數。為什么呢？
我們假設線程 A 和線程 B 同時開始執行，那么第一次都會將 count=0 讀到各自的 CPU 緩存里，執行完 count+=1 之后，各自 CPU 緩存里的值都是 1，同時寫入內存后，我們會發現內存中是 1，而不是我們期望的 2。之后由于各自的 CPU 緩存里都有了 count 的值，兩個線程都是基于 CPU 緩存里的 count 值來計算，所以導致最終 count 的值都是小于20000 的。這就是緩存的可見性問題。
循環 10000 次 count+=1 操作如果改為循環 1 億次，你會發現效果更明顯，最終 count的值接近 1 億，而不是 2 億。如果循環 10000 次，count 的值接近 20000，原因是兩個線程不是同時啟動的，有一個時差。
變量 count 在 CPU 緩存和內存的分布圖
源頭之二：線程切換帶來的原子性問題
由于 IO 太慢，早期的操作系統就發明了多進程，即便在單核的 CPU 上我們也可以一邊聽著歌，一邊寫 Bug，這個就是多進程的功勞。
操作系統允許某個進程執行一小段時間，例如 50 毫秒，過了 50 毫秒操作系統就會重新選擇一個進程來執行（我們稱為“任務切換”），這個 50 毫秒稱為“時間片”。
線程切換示意圖
在一個時間片內，如果一個進程進行一個 IO 操作，例如讀個文件，這個時候該進程可以把自己標記為“休眠狀態”并出讓 CPU 的使用權，待文件讀進內存，操作系統會把這個休眠的進程喚醒，喚醒后的進程就有機會重新獲得 CPU 的使用權了。
這里的進程在等待 IO 時之所以會釋放 CPU 使用權，是為了讓 CPU 在這段等待時間里可以做別的事情，這樣一來 CPU 的使用率就上來了；此外，如果這時有另外一個進程也讀文件，讀文件的操作就會排隊，磁盤驅動在完成一個進程的讀操作后，發現有排隊的任務，就會立即啟動下一個讀操作，這樣 IO 的使用率也上來了。
是不是很簡單的邏輯？但是，雖然看似簡單，支持多進程分時復用在操作系統的發展史上卻具有里程碑意義，Unix 就是因為解決了這個問題而名噪天下的。
早期的操作系統基于進程來調度 CPU，不同進程間是不共享內存空間的，所以進程要做任務切換就要切換內存映射地址，而一個進程創建的所有線程，都是共享一個內存空間的，所以線程做任務切換成本就很低了。現代的操作系統都基于更輕量的線程來調度，現在我們提到的“任務切換”都是指“線程切換”。
JAVA 并發程序都是基于多線程的，自然也會涉及到任務切換，也許你想不到，任務切換竟然也是并發編程里詭異 Bug 的源頭之一。任務切換的時機大多數是在時間片結束的時候，我們現在基本都使用高級語言編程，高級語言里一條語句往往需要多條 CPU 指令完成，例如上面代碼中的count += 1，至少需要三條 CPU 指令。
- 指令 1：首先，需要把變量 count 從內存加載到 CPU 的寄存器；
- 指令 2：之后，在寄存器中執行 +1 操作；
- 指令 3：最后，將結果寫入內存（緩存機制導致可能寫入的是 CPU 緩存而不是內存）。
操作系統做任務切換，可以發生在任何一條CPU 指令執行完，是的，是 CPU 指令，而不是高級語言里的一條語句。對于上面的三條指令來說，我們假設 count=0，如果線程 A 在指令 1 執行完后做線程切換，線程 A 和線程 B 按照下圖的序列執行，那么我們會發現兩個線程都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1。
非原子操作的執行路徑示意圖
我們潛意識里面覺得 count+=1 這個操作是一個不可分割的整體，就像一個原子一樣，線程的切換可以發生在 count+=1 之前，也可以發生在 count+=1 之后，但就是不會發生在中間。我們把一個或者多個操作在 CPU 執行的過程中不被中斷的特性稱為原子性。CPU能保證的原子操作是 CPU 指令級別的，而不是高級語言的操作符，這是違背我們直覺的地方。因此，很多時候我們需要在高級語言層面保證操作的原子性。
源頭之三：編譯優化帶來的有序性問題
那并發編程里還有沒有其他有違直覺容易導致詭異 Bug 的技術呢？有的，就是有序性。顧名思義，有序性指的是程序按照代碼的先后順序執行。編譯器為了優化性能，有時候會改變程序中語句的先后順序，例如程序中：“a=6；b=7；”編譯器優化后可能變成“b=7；a=6；”，在這個例子中，編譯器調整了語句的順序，但是不影響程序的最終結果。不過有時候編譯器及解釋器的優化可能導致意想不到的 Bug。
在 Java 領域一個經典的案例就是利用雙重檢查創建單例對象，例如下面的代碼：在獲取實例 getInstance() 的方法中，我們首先判斷 instance 是否為空，如果為空，則鎖定Singleton.class 并再次檢查 instance 是否為空，如果還為空則創建 Singleton 的一個實例。
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 實例。
這看上去一切都很完美，無懈可擊，但實際上這個 getInstance() 方法并不完美。問題出在哪里呢？出在 new 操作上，我們以為的 new 操作應該是：
- 1. 分配一塊內存 M；
- 2. 在內存 M 上初始化 Singleton 對象；
- 3. 然后 M 的地址賦值給 instance 變量。
但是實際上優化后的執行路徑卻是這樣的：
- 1. 分配一塊內存 M；
- 2. 將 M 的地址賦值給 instance 變量；
- 3. 最后在內存 M 上初始化 Singleton 對象。
優化后會導致什么問題呢？我們假設線程 A 先執行 getInstance() 方法，當執行完指令 2時恰好發生了線程切換，切換到了線程 B 上；如果此時線程 B 也執行 getInstance() 方法，那么線程 B 在執行第一個判斷時會發現 instance != null ，所以直接返回instance，而此時的 instance 是沒有初始化過的，如果我們這個時候訪問 instance 的成員變量就可能觸發空指針異常。
雙重檢查創建單例的異常執行路徑
總結
要寫好并發程序，首先要知道并發程序的問題在哪里，只有確定了“靶子”，才有可能把問題解決，畢竟所有的解決方案都是針對問題的。并發程序經常出現的詭異問題看上去非常無厘頭，但是深究的話，無外乎就是直覺欺騙了我們，只要我們能夠深刻理解可見性、原子性、有序性在并發場景下的原理，很多并發 Bug 都是可以理解、可以診斷的。
在介紹可見性、原子性、有序性的時候，特意提到緩存導致的可見性問題，線程切換帶來的原子性問題，編譯優化帶來的有序性問題，其實緩存、線程、編譯優化的目的和我們寫并發程序的目的是相同的，都是提高程序性能。但是技術在解決一個問題的同時，必然會帶來另外一個問題，所以在采用一項技術的同時，一定要清楚它帶來的問題是什么，以及如何規避。
