某日,胖滾豬寫的代碼導致了一個生產bug,奮戰到凌晨三點依舊沒有解決問題。胖滾熊一看,只用了一個volatile就解決了。並告知胖滾豬,這是併發編程導致的坑。這讓胖滾豬堅定了要學好併發編程的決心。。於是,開始了我們併發編程的第一課。
序幕
BUG源頭之一:可見性
剛剛我們說到,CPU緩存可以提高程序性能,但緩存也是造成BUG源頭之一,因爲緩存可以導致可見性問題。我們先來看一段代碼:
private static int count = 0;
public static void main(String[] args) throws Exception {
Thread th1 = new Thread(() -> {
count = 10;
});
Thread th2 = new Thread(() -> {
//極小概率會出現等於0的情況
System.out.println("count=" + count);
});
th1.start();
th2.start();
}
按理來說,應該正確返回10,但結果卻有可能是0。
一個線程對變量的改變另一個線程沒有get到,這就是可見性導致的bug。一個線程對共享變量的修改,另外一個線程能夠立刻看到,我們稱爲可見性。
那麼在談論可見性問題之前,你必須瞭解下JAVA的內存模型,我繪製了一張圖來描述:
主內存(Main Memory)
主內存可以簡單理解爲計算機當中的內存,但又不完全等同。主內存被所有的線程所共享,對於一個共享變量(比如靜態變量,或是堆內存中的實例)來說,主內存當中存儲了它的“本尊”。
工作內存(Working Memory)
工作內存可以簡單理解爲計算機當中的CPU高速緩存,但準確的說它是涵蓋了緩存、寫緩衝區、寄存器以及其他的硬件和編譯器優化。每一個線程擁有自己的工作內存,對於一個共享變量來說,工作內存當中存儲了它的“副本”。
線程對變量的所有操作都必須在工作內存中進行,而不能直接讀寫主內存中的變量。
線程之間無法直接訪問對方的工作內存中的變量,線程間變量的傳遞均需要通過主內存來完成
現在再回到剛剛的問題,爲什麼那段代碼會導致可見性問題呢,根據內存模型來分析,我相信你會有答案了。當多個線程在不同的 CPU 上執行時,這些線程操作的是不同的 CPU 緩存。比如下圖中,線程 A 操作的是 CPU-1 上的緩存,而線程 B 操作的是 CPU-2 上的緩存
由於線程對變量的所有操作都必須在工作內存中進行,而不能直接讀寫主內存中的變量,那麼對於共享變量V,它們首先是在自己的工作內存,之後再同步到主內存。可是並不會及時的刷到主存中,而是會有一定時間差。很明顯,這個時候線程 A 對變量 V 的操作對於線程 B 而言就不具備可見性了 。
private volatile long count = 0;
private void add10K() {
int idx = 0;
while (idx++ < 10000) {
count++;
}
}
public static void main(String[] args) throws InterruptedException {
TestVolatile2 test = new TestVolatile2();
// 創建兩個線程,執行 add() 操作
Thread th1 = new Thread(()->{
test.add10K();
});
Thread th2 = new Thread(()->{
test.add10K();
});
// 啓動兩個線程
th1.start();
th2.start();
// 等待兩個線程執行結束
th1.join();
th2.join();
// 介於1w-2w,即使加了volatile也達不到2w
System.out.println(test.count);
}
原子性問題
一個不可分割的操作叫做原子性操作,它不會被線程調度機制打斷的,這種操作一旦開始,就一直運行到結束,中間不會有任何線程切換。注意線程切換是重點!
我們都知道CPU資源的分配都是以線程爲單位的,並且是分時調用,操作系統允許某個進程執行一小段時間,例如 50 毫秒,過了 50 毫秒操作系統就會重新選擇一個進程來執行(我們稱爲“任務切換”),這個 50 毫秒稱爲“時間片”。而任務的切換大多數是在時間片段結束以後,
那麼線程切換爲什麼會帶來bug呢?因爲操作系統做任務切換,可以發生在任何一條CPU 指令執行完!注意,是 CPU 指令,CPU 指令,CPU 指令,而不是高級語言裏的一條語句。比如count++,在java裏就是一句話,但高級語言裏一條語句往往需要多條 CPU 指令完成。其實count++包含了三個CPU指令!
-
指令 1:首先,需要把變量 count 從內存加載到 CPU 的寄存器;
-
指令 2:之後,在寄存器中執行 +1 操作;
-
指令 3:最後,將結果寫入內存(緩存機制導致可能寫入的是 CPU 緩存而不是內存)。
小技巧:可以寫一個簡單的count++程序,依次執行javac TestCount.java,javap -c -s TestCount.class得到彙編指令,驗證下count++確實是分成了多條指令的。
volatile雖然能保證執行完及時把變量刷到主內存中,但對於count++這種非原子性、多指令的情況,由於線程切換,線程A剛把count=0加載到工作內存,線程B就可以開始工作了,這樣就會導致線程A和B執行完的結果都是1,都寫到主內存中,主內存的值還是1不是2,下面這張圖形象表示了該歷程:
有序性問題
JAVA爲了優化性能,允許編譯器和處理器對指令進行重排序,即有時候會改變程序中語句的先後順序:
例如程序中:“a=6;b=7;”編譯器優化後可能變成“b=7;a=6;”只是在這個程序中不影響程序的最終結果。
有序性指的是程序按照代碼的先後順序執行。但是不要望文生義,這裏的順序不是按照代碼位置的依次順序執行指令,指的是最終結果在我們看起來就像是有序的。
重排序的過程不會影響單線程程序的執行,卻會影響到多線程併發執行的正確性。有時候編譯器及解釋器的優化可能導致意想不到的 Bug。比如非常經典的雙重檢查創建單例對象。
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
你可能會覺得這個程序天衣無縫,我兩次判斷是否爲空,還用了synchronized,剛剛也說了,synchronized 是獨佔鎖/排他鎖。按照常理來說,應該是這麼一個邏輯:
線程A和B同時進來,判斷instance == null,線程A先獲取了鎖,B等待,然後線程 A 會創建一個 Singleton 實例,之後釋放鎖,鎖釋放後,線程 B 被喚醒,線程 B 再次嘗試加鎖,此時加鎖會成功,然後線程 B 檢查 instance == null 時會發現,已經創建過 Singleton 實例了,所以線程 B 不會再創建一個 Singleton 實例。
但多線程往往要有非常理性的思維,我們先分析一下 instance = new Singleton()這句話,根據剛剛原子性說到的,一句高級語言在cpu層面其實是多條指令,這也不例外,我們也很熟悉new了,它會分爲以下幾條指令:
1、分配一塊內存 M;
2、在內存 M 上初始化 Singleton 對象;
3、然後 M 的地址賦值給 instance 變量。
如果真按照上述三條指令執行是沒問題的,但經過編譯優化後的執行路徑卻是這樣的:
**1、分配一塊內存 M;
2、將 M 的地址賦值給 instance 變量;
3、最後在內存 M 上初始化 Singleton 對象**
假如當執行完指令 2 時恰好發生了線程切換,切換到了線程 B 上;而此時線程 B 也執行 getInstance() 方法,那麼線程 B 在執行第一個判斷時會發現 instance != null ,所以直接返回 instance,而此時的 instance 是沒有初始化過的,如果我們這個時候訪問 instance 的成員變量就可能觸發空指針異常,如圖所示:
總結
併發程序是一把雙刃劍,一方面大幅度提升了程序性能,另一方面帶來了很多隱藏的無形的難以發現的bug。我們首先要知道併發程序的問題在哪裏,只有確定了“靶子”,纔有可能把問題解決,畢竟所有的解決方案都是針對問題的。併發程序經常出現的詭異問題看上去非常無厘頭,但是隻要我們能夠深刻理解可見性、原子性、有序性在併發場景下的原理,很多併發 Bug 都是可以理解、可以診斷的。
總結一句話:可見性是緩存導致的,而線程切換會帶來的原子性問題,編譯優化會帶來有序性問題。至於怎麼解決呢!欲知後事如何,且聽下回分解。