可見性、原子性和有序性問題：并發(fā)編程Bug的源頭
并發(fā)程序幕后的故事
這些年，我們的 CPU、內(nèi)存、I/O 設(shè)備都在不斷迭代，不斷朝著更快的方向努力。但是，在這個(gè)快速發(fā)展的過程中，有一個(gè)核心矛盾一直存在，就是這三者的速度差異。CPU 和內(nèi)存的速度差異可以形象地描述為：CPU 是天上一天，內(nèi)存是地上一年（假設(shè) CPU 執(zhí)行一條普通指令需要一天，那么 CPU 讀寫內(nèi)存得等待一年的時(shí)間）。內(nèi)存和 I/O 設(shè)備的速度差異就更大了，內(nèi)存是天上一天，I/O 設(shè)備是地上十年。
程序里大部分語句都要訪問內(nèi)存，有些還要訪問 I/O，根據(jù)木桶理論（一只水桶能裝多少水取決于它最短的那塊木板），程序整體的性能取決于最慢的操作——讀寫 I/O 設(shè)備，也就是說單方面提高 CPU 性能是無效的。
為了合理利用 CPU 的高性能，平衡這三者的速度差異，計(jì)算機(jī)體系機(jī)構(gòu)、操作系統(tǒng)、編譯程序都做出了貢獻(xiàn)，主要體現(xiàn)為：
- CPU 增加了緩存，以均衡與內(nèi)存的速度差異；
- 操作系統(tǒng)增加了進(jìn)程、線程，以分時(shí)復(fù)用 CPU，進(jìn)而均衡 CPU 與 I/O 設(shè)備的速度差異；
- 編譯程序優(yōu)化指令執(zhí)行次序，使得緩存能夠得到更加合理地利用。
現(xiàn)在我們幾乎所有的程序都默默地享受著這些成果，但是天下沒有免費(fèi)的午餐，并發(fā)程序很多詭異問題的根源也在這里。
源頭之一：緩存導(dǎo)致的可見性問題
在單核時(shí)代，所有的線程都是在一顆 CPU 上執(zhí)行，CPU 緩存與內(nèi)存的數(shù)據(jù)一致性容易解決。因?yàn)樗芯€程都是操作同一個(gè) CPU 的緩存，一個(gè)線程對(duì)緩存的寫，對(duì)另外一個(gè)線程來說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個(gè) CPU 里面的緩存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的最新值（線程 A 寫過的值）。
CPU 緩存與內(nèi)存的關(guān)系圖
一個(gè)線程對(duì)共享變量的修改，另外一個(gè)線程能夠立刻看到，我們稱為可見性。
多核時(shí)代，每顆 CPU 都有自己的緩存，這時(shí) CPU 緩存與內(nèi)存的數(shù)據(jù)一致性就沒那么容易解決了，當(dāng)多個(gè)線程在不同的 CPU 上執(zhí)行時(shí)，這些線程操作的是不同的 CPU 緩存。比如下圖中，線程 A 操作的是 CPU-1 上的緩存，而線程 B 操作的是 CPU-2 上的緩存，很明顯，這個(gè)時(shí)候線程 A 對(duì)變量 V 的操作對(duì)于線程 B 而言就不具備可見性了。
多核 CPU 的緩存與內(nèi)存關(guān)系圖
我們?cè)儆靡欢未a來驗(yàn)證一下多核場景下的可見性問題。下面的代碼，每執(zhí)行一次 add10K() 方法，都會(huì)循環(huán) 10000 次 count+=1 操作。在 calc() 方法中我們創(chuàng)建了兩個(gè)線程，每個(gè)線程調(diào)用一次 add10K() 方法，我們來想一想執(zhí)行 calc() 方法得到的結(jié)果應(yīng)該是多少呢？
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();
// 創(chuàng)建兩個(gè)線程，執(zhí)行 add() 操作
Thread th1 = new Thread(()->{
test.add10K();
});
Thread th2 = new Thread(()->{
test.add10K();
});
// 啟動(dòng)兩個(gè)線程
th1.start();
th2.start();
// 等待兩個(gè)線程執(zhí)行結(jié)束
th1.join();
th2.join();
return count;
}
}直覺告訴我們應(yīng)該是 20000，因?yàn)樵趩尉€程里調(diào)用兩次 add10K() 方法，count 的值就是 20000，但實(shí)際上 calc() 的執(zhí)行結(jié)果是個(gè) 10000 到 20000 之間的隨機(jī)數(shù)。為什么呢？
我們假設(shè)線程 A 和線程 B 同時(shí)開始執(zhí)行，那么第一次都會(huì)將 count=0 讀到各自的 CPU 緩存里，執(zhí)行完 count+=1 之后，各自 CPU 緩存里的值都是 1，同時(shí)寫入內(nèi)存后，我們會(huì)發(fā)現(xiàn)內(nèi)存中是 1，而不是我們期望的 2。之后由于各自的 CPU 緩存里都有了 count 的值，兩個(gè)線程都是基于 CPU 緩存里的 count 值來計(jì)算，所以導(dǎo)致最終 count 的值都是小于 20000 的。這就是緩存的可見性問題。
變量 count 在 CPU 緩存和內(nèi)存的分布圖
源頭之二：線程切換帶來的原子性問題
由于 IO 太慢，早期的操作系統(tǒng)就發(fā)明了多進(jìn)程，即便在單核的 CPU 上我們也可以一邊聽著歌，一邊寫 Bug，這個(gè)就是多進(jìn)程的功勞。操作系統(tǒng)允許某個(gè)進(jìn)程執(zhí)行一小段時(shí)間，例如 50 毫秒，過了 50 毫秒操作系統(tǒng)就會(huì)重新選擇一個(gè)進(jìn)程來執(zhí)行（我們稱為“任務(wù)切換”），這個(gè) 50 毫秒稱為“時(shí)間片”。
線程切換示意圖
在一個(gè)時(shí)間片內(nèi)，如果一個(gè)進(jìn)程進(jìn)行一個(gè) IO 操作，例如讀個(gè)文件，這個(gè)時(shí)候該進(jìn)程可以把自己標(biāo)記為“休眠狀態(tài)”并出讓 CPU 的使用權(quán)，待文件讀進(jìn)內(nèi)存，操作系統(tǒng)會(huì)把這個(gè)休眠的進(jìn)程喚醒，喚醒后的進(jìn)程就有機(jī)會(huì)重新獲得 CPU 的使用權(quán)了。
這里的進(jìn)程在等待 IO 時(shí)之所以會(huì)釋放 CPU 使用權(quán)，是為了讓 CPU 在這段等待時(shí)間里可以做別的事情，這樣一來 CPU 的使用率就上來了；此外，如果這時(shí)有另外一個(gè)進(jìn)程也讀文件，讀文件的操作就會(huì)排隊(duì)，磁盤驅(qū)動(dòng)在完成一個(gè)進(jìn)程的讀操作后，發(fā)現(xiàn)有排隊(duì)的任務(wù)，就會(huì)立即啟動(dòng)下一個(gè)讀操作，這樣 IO 的使用率也上來了。
早期的操作系統(tǒng)基于進(jìn)程來調(diào)度 CPU，不同進(jìn)程間是不共享內(nèi)存空間的，所以進(jìn)程要做任務(wù)切換就要切換內(nèi)存映射地址，而一個(gè)進(jìn)程創(chuàng)建的所有線程，都是共享一個(gè)內(nèi)存空間的，所以線程做任務(wù)切換成本就很低了?，F(xiàn)代的操作系統(tǒng)都基于更輕量的線程來調(diào)度，現(xiàn)在我們提到的“任務(wù)切換”都是指“線程切換”。
Java 并發(fā)程序都是基于多線程的，自然也會(huì)涉及到任務(wù)切換，也許你想不到，任務(wù)切換竟然也是并發(fā)編程里詭異 Bug 的源頭之一。任務(wù)切換的時(shí)機(jī)大多數(shù)是在時(shí)間片結(jié)束的時(shí)候，我們現(xiàn)在基本都使用高級(jí)語言編程，高級(jí)語言里一條語句往往需要多條 CPU 指令完成，例如上面代碼中的count += 1，至少需要三條 CPU 指令。
- 指令 1：首先，需要把變量 count 從內(nèi)存加載到 CPU 的寄存器；
- 指令 2：之后，在寄存器中執(zhí)行 +1 操作；
- 指令 3：最后，將結(jié)果寫入內(nèi)存（緩存機(jī)制導(dǎo)致可能寫入的是 CPU 緩存而不是內(nèi)存）。
操作系統(tǒng)做任務(wù)切換，可以發(fā)生在任何一條CPU 指令執(zhí)行完，是的，是 CPU 指令，而不是高級(jí)語言里的一條語句。對(duì)于上面的三條指令來說，我們假設(shè) count=0，如果線程 A 在指令 1 執(zhí)行完后做線程切換，線程 A 和線程 B 按照下圖的序列執(zhí)行，那么我們會(huì)發(fā)現(xiàn)兩個(gè)線程都執(zhí)行了 count+=1 的操作，但是得到的結(jié)果不是我們期望的 2，而是 1。
非原子操作的執(zhí)行路徑示意圖
我們潛意識(shí)里面覺得 count+=1 這個(gè)操作是一個(gè)不可分割的整體，就像一個(gè)原子一樣，線程的切換可以發(fā)生在 count+=1 之前，也可以發(fā)生在 count+=1 之后，但就是不會(huì)發(fā)生在中間。我們把一個(gè)或者多個(gè)操作在 CPU 執(zhí)行的過程中不被中斷的特性稱為原子性。CPU 能保證的原子操作是 CPU 指令級(jí)別的，而不是高級(jí)語言的操作符，這是違背我們直覺的地方。因此，很多時(shí)候我們需要在高級(jí)語言層面保證操作的原子性。
源頭之三：編譯優(yōu)化帶來的有序性問題
有序性。顧名思義，有序性指的是程序按照代碼的先后順序執(zhí)行。編譯器為了優(yōu)化性能，有時(shí)候會(huì)改變程序中語句的先后順序，例如程序中：“a=6；b=7；”編譯器優(yōu)化后可能變成“b=7；a=6；”，在這個(gè)例子中，編譯器調(diào)整了語句的順序，但是不影響程序的最終結(jié)果。不過有時(shí)候編譯器及解釋器的優(yōu)化可能導(dǎo)致意想不到的 Bug。
在 Java 領(lǐng)域一個(gè)經(jīng)典的案例就是利用雙重檢查創(chuàng)建單例對(duì)象，例如下面的代碼：在獲取實(shí)例 getInstance() 的方法中，我們首先判斷 instance 是否為空，如果為空，則鎖定 Singleton.class 并再次檢查 instance 是否為空，如果還為空則創(chuàng)建 Singleton 的一個(gè)實(shí)例。
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}假設(shè)有兩個(gè)線程 A、B 同時(shí)調(diào)用 getInstance() 方法，他們會(huì)同時(shí)發(fā)現(xiàn) instance == null
，于是同時(shí)對(duì) Singleton.class 加鎖，此時(shí) JVM 保證只有一個(gè)線程能夠加鎖成功（假設(shè)是線程 A），另外一個(gè)線程則會(huì)處于等待狀態(tài)（假設(shè)是線程 B）；線程 A 會(huì)創(chuàng)建一個(gè) Singleton 實(shí)例，之后釋放鎖，鎖釋放后，線程 B 被喚醒，線程 B 再次嘗試加鎖，此時(shí)是可以加鎖成功的，加鎖成功后，線程 B 檢查 instance == null 時(shí)會(huì)發(fā)現(xiàn)，已經(jīng)創(chuàng)建過 Singleton 實(shí)例了，所以線程 B 不會(huì)再創(chuàng)建一個(gè) Singleton 實(shí)例。
這看上去一切都很完美，無懈可擊，但實(shí)際上這個(gè) getInstance() 方法并不完美。問題出在哪里呢？出在 new 操作上，我們以為的 new 操作應(yīng)該是：
- 分配一塊內(nèi)存 M；
- 在內(nèi)存 M 上初始化 Singleton 對(duì)象；
- 然后 M 的地址賦值給 instance 變量。
但是實(shí)際上優(yōu)化后的執(zhí)行路徑卻是這樣的：
- 分配一塊內(nèi)存 M；
- 將 M 的地址賦值給 instance 變量；
- 最后在內(nèi)存 M 上初始化 Singleton 對(duì)象。
優(yōu)化后會(huì)導(dǎo)致什么問題呢？我們假設(shè)線程 A 先執(zhí)行 getInstance() 方法，當(dāng)執(zhí)行完指令 2 時(shí)恰好發(fā)生了線程切換，切換到了線程 B 上；如果此時(shí)線程 B 也執(zhí)行 getInstance() 方法，那么線程 B 在執(zhí)行第一個(gè)判斷時(shí)會(huì)發(fā)現(xiàn) instance != null，所以直接返回 instance，而此時(shí)的 instance 是沒有初始化過的，如果我們這個(gè)時(shí)候訪問 instance 的成員變量就可能觸發(fā)空指針異常。
雙重檢查創(chuàng)建單例的異常執(zhí)行路徑
總結(jié)
要寫好并發(fā)程序，首先要知道并發(fā)程序的問題在哪里，只有確定了“靶子”，才有可能把問題解決，畢竟所有的解決方案都是針對(duì)問題的。并發(fā)程序經(jīng)常出現(xiàn)的詭異問題看上去非常無厘頭，但是深究的話，無外乎就是直覺欺騙了我們，只要我們能夠深刻理解可見性、原子性、有序性在并發(fā)場景下的原理，很多并發(fā) Bug 都是可以理解、可以診斷的。
