前言
編寫正确的并發程式是一件極困難的事情，并發程式的 Bug 很難重制，也很難追蹤，很多時候都讓人很抓狂。
并發程式設計是怎麼出問題的？這些年，我們的 CPU、記憶體、I/O 裝置都在不斷更新疊代，在這個快速發展的過程中，有一個核心沖突一直存在，就是這三者的速度差異：CPU的速度遠遠高于記憶體，記憶體的速度又遠遠高于I/O。程式裡大部分語句都要通路記憶體，有些還要通路 I/O，即使CPU速度再快，I/O跟不上也不能改善程式運作速度。
後來，有了一系列方法來改善：
- CPU 增加了緩存，均衡與記憶體的速度差異；
- 作業系統增加了程序、線程，以分時複用 CPU，進而均衡 CPU 與 I/O 裝置的速度差異；
- 編譯程式優化指令執行次序，使得緩存能夠得到更加合理地利用。
并發程式很多詭異問題的根源也在這裡。
一：緩存導緻的可見性問題
在單核時代，所有的線程都是在一顆 CPU 上執行，CPU 緩存與記憶體的資料一緻性容易解決。因為所有線程都是操作同一個 CPU 的緩存，一個線程對緩存的寫，對另外一個線程來說一定是可見的。
例如在下面的圖中，線程 A 和線程 B 都是操作同一個 CPU 裡面的緩存，是以線程 A 更新了變量 V 的值，那麼線程 B 之後再通路變量 V，得到的一定是 V 的最新值（線程 A 寫過的值）。
一個線程對共享變量的修改，另外一個線程能夠立刻看到，我們稱為可見性。
多核時代，每顆 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，原因是兩個線程不是同時啟動的，有一個時差。
二：線程切換帶來的原子性問題
由于 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 操作應該是：
- 配置設定一塊記憶體 M；
- 在記憶體 M 上初始化 Singleton 對象；
- 然後 M 的位址指派給 instance 變量。
但是實際上優化後的執行路徑卻是這樣的：
- 配置設定一塊記憶體 M；
- 将 M 的位址指派給 instance 變量；
- 最後在記憶體 M 上初始化 Singleton 對象。
優化後會導緻什麼問題呢？我們假設線程 A 先執行 getInstance() 方法，當執行完指令 2 時恰好發生了線程切換，切換到了線程 B 上；如果此時線程 B 也執行 getInstance() 方法，那麼線程 B 在執行第一個判斷時會發現 instance != null ，是以直接傳回 instance，而此時的 instance 是沒有初始化過的，如果我們這個時候通路 instance 的成員變量就可能觸發空指針異常。
總結
在介紹可見性、原子性、有序性的時候，特意提到緩存導緻的可見性問題，線程切換帶來的原子性問題，編譯優化帶來的有序性問題，其實緩存、線程、編譯優化的目的和我們寫并發程式的目的是相同的，都是提高程式性能。但是技術在解決一個問題的同時，必然會帶來另外一個問題，是以在采用一項技術的同時，一定要清楚它帶來的問題是什麼，以及如何規避。