你的Java并發(fā)程序Bug，100%是這幾個原因造成的
可見性問題
可見性是指一個線程對共享變量進行了修改，其他線程能夠立馬看到該共享變量更新后的值，這視乎是一個合情合理的要求，但是在多線程的情況下，可能就要讓你失望了，由于每個 CPU 都有自己的緩存，每個線程使用的可能是不同的 CPU ，這就會出現(xiàn)數(shù)據(jù)可見性的問題，先來看看下面這張圖：
CUP 緩存與主內(nèi)存的關(guān)系
對于一個共享變量 count ，每個 CPU 緩存中都有一個 count 副本，每個線程對共享變量 count 的操作的只能操作自己所在 CPU 緩存中的副本，不能直接操作主存或者其他 CPU 緩存中的副本，這也就產(chǎn)生了數(shù)據(jù)差異。由于可見性在多線程情況下造成程序問題的典型案例就是變量的累加，如下面這段程序：
- public class Demo {
- private int count = 0;
- // 每個線程為count + 10000
- public void add() {
- for (int i = 0; i < 10000; i++) {
- count += 1;
- }
- }
- public static void main(String[] args) throws InterruptedException {
- for (int i = 0; i < 10; i++) {
- Demo demo = new Demo();
- Thread t1 = new Thread(() -> {
- demo.add();
- });
- Thread t2 = new Thread(() -> {
- demo.add();
- });
- t1.start();
- t2.start();
- t1.join();
- t2.join();
- System.out.println(demo.count);
- }
- }
- }
我們使用了 2 個程序?qū)?count 變量累加，每個線程累加 10000 次，按道理來說最終結(jié)果應(yīng)該是 20000 次，但是你多次執(zhí)行后，你會發(fā)現(xiàn)結(jié)果不一定是 20000 次，這就是由于共享變量的可見性造成的。
我們啟動了兩個線程 t1 和 t2，線程啟動的時候會把當(dāng)前主內(nèi)存的 count 讀入到自己的 CPU 緩存當(dāng)中，這時候 count 的值可能是 0 也可能是 1 或者其他，我們就默認(rèn)為 0，每個線程都會執(zhí)行 count += 1 操作，這是一個并行操作，CPU1 和 CPU2 緩存中的 count 都是 1，然后他們分別將自己緩存中的count 寫回到主內(nèi)存中，這時候主內(nèi)存中的 count 也是 1 ，并不是我們預(yù)計的 2,。這個原因就是數(shù)據(jù)可見性造成的。
原子性問題
原子性：即一個操作或者多個操作，要么全部執(zhí)行并且執(zhí)行的過程不會被任何因素打斷，要么就都不執(zhí)行。這個原子性針對的是 CPU 級別的，并不是我們 Java 代碼里面的原子性，拿我們可見性 Demo 程序中的 count += 1;命令為例，這一條 Java 命令最終會被編譯成如下三條 CPU 指令：
- 把變量 count 從內(nèi)存加載到 CPU 的寄存器，假設(shè) count = 1
- 在寄存器中執(zhí)行 count +1 操作，count = 1+1 =2
- 將結(jié)果 +1 后的 count 寫入內(nèi)存
這是一個典型的 讀-改-寫 的操作，但是它不是原子性的，因為 多核CPU 之間有競爭關(guān)系，并不是某一個 CPU 一直執(zhí)行，他們會不斷的搶占執(zhí)行權(quán)、釋放執(zhí)行權(quán)，所以上面三條指令就不一定是原子性的，下圖是兩個線程 count += 1命令的模擬流程：
非原子性操作
線程1 所在的 CPU 執(zhí)行完前兩條指令后，執(zhí)行權(quán)被 線程2 所在的 CPU 搶占了，這時候線程1 所在的 CPU 執(zhí)行掛起等待再次獲取執(zhí)行權(quán)，線程2 所在的 CPU 獲取到執(zhí)行權(quán)之后，先從內(nèi)存中讀取 count，此時內(nèi)存中的 count 還是 1，線程2 所在的 CPU 恰好執(zhí)行完了這三條指令，線程2 執(zhí)行完之后內(nèi)存中的 count 就等于 2 了，這時候線程1 再次獲取了執(zhí)行權(quán)，這時候線程1 只剩下最后一條將 count 寫回內(nèi)存的命令，執(zhí)行完之后，內(nèi)存中的 count 的值還是 2 ，并不是我們預(yù)計的 3。
有序性問題
有序性：程序執(zhí)行的順序按照代碼的先后順序執(zhí)行，比如下面這段代碼
- 1 int i = 1;
- 2 int m = 11;
- 3 long x = 23L;
按照有序性的話就需要按照代碼的順序執(zhí)行下來，但是執(zhí)行結(jié)果不一定是按照這個順序來的，因為 JVM 為了提高程序的運行效率，會對上面的代碼按照 JVM 編譯器認(rèn)為較好的順序執(zhí)行，從而可能打亂代碼的執(zhí)行順序，是它會保證程序最終執(zhí)行結(jié)果和代碼順序執(zhí)行的結(jié)果是一致的，這也就是我們所說的指令重排序
由于指令重排序造成程序出 Bug 的典型案例就是：未加 volatile 關(guān)鍵字的雙重檢測鎖單例模式，如下代碼：
- public class Singleton {
- static Singleton instance;
- public static Singleton getInstance(){
- // 第一次判斷
- if (instance == null) {
- // 加鎖，只有一個線程能夠獲取鎖
- synchronized(Singleton.class) {
- // 第二次判斷
- if (instance == null)
- // 構(gòu)建對象，這里面就非常有學(xué)問了
- instance = new Singleton();
- }
- }
- return instance;
- }
- }
雙重檢測鎖方案看上去非常完美，但是在實際運行時卻會出 Bug，會出現(xiàn)對象逸出的問題，可能會得到一個未構(gòu)建完的 Singleton 對象， 這個就是在構(gòu)建 Singleton 對象時指令重排序的問題。我們先來看看構(gòu)建對象理想型的操作指令：
- 指令1：分配一塊內(nèi)存 M;
- 指令2：在內(nèi)存 M 上初始化 Singleton 對象;
- 指令3：然后 M 的地址賦值給 instance 變量。
但是實際在 JVM 編譯器上可能不是這樣，可能會被優(yōu)化成如下指令：
- 指令1：分配一塊內(nèi)存 M;
- 指令2：將 M 的地址賦值給 instance 變量;
- 指令3：最后在內(nèi)存 M 上初始化 Singleton 對象。
看上去一個小小的優(yōu)化，也就是這么一個小小的優(yōu)化就會使你的程序不安全，假設(shè)搶到鎖的線程執(zhí)行完指令2 之后，此時的 instance 已經(jīng)不為空了，這時候來了線程C，線程C 看到的 instance 已經(jīng)是不為空的了，就會直接返回 instance 對象，這時候的 instance 并未初始化成功，調(diào)用 instance 對象的方法或者成員變量時將有可能觸發(fā)空指針異常?？赡艿膱?zhí)行流程圖：
未加 volatile 關(guān)鍵字的雙重檢測鎖單例模式
上面就是造成 Java 程序在多線程情況下出 Bug 的三種原因，關(guān)于這些問題 JDK 公司也給出了相應(yīng)的解決辦法，具體如下圖所示，這些解決辦法的更多細(xì)節(jié)，我們后面在細(xì)細(xì)道來。
并發(fā)解決機制
