上次帥地問的問題，讓小秋學習了不少。這幾天小秋剛好學習了一些設計模式的知識，這不，又跑去找?guī)浀靥接懸恍﹩栴}了。

粗糙的同步

小秋：地哥，上次你問的問題，讓我收獲頗多，這些天我大致研究了下設計模式，帥地有什么指教的嗎？

帥地：小子，行啊。那我再考考你得了。

此刻小秋聚精會神著等帥地又會拋出哪些問題.....

帥地：學過單例模式吧？單例模式有多種寫法，寫一種出來看看。

小秋：好啊，聽說單例模式是面試中問的最多的一種模式，對于單例模式的幾種的寫法，我可以相當熟練哦（有點得意）。

于是，小秋甩手就寫了一種懶漢模式的代碼出來

public class Singleton {
    private Singleton instance = null;
    //私有構(gòu)造函數(shù)
    private Singleton(){};
    
    public Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

懶漢模式：就是等到有線程調(diào)用getInstance這個方法時，才來創(chuàng)建對象實例。與懶漢模式相反的是餓漢模式，下篇會講到。

帥地：夠熟練的你，不過你這段代碼并非線程安全的，怎么辦？

小秋：嘿嘿，簡單，看我的。

public class Singleton {
    private Singleton instance = null;
    //私有構(gòu)造函數(shù)
    private Singleton(){};
    
    //多了個synchronized關鍵字
    public   synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

注：不清楚synchronized關鍵字的可以看我之前寫的文章：線程安全(上)--徹底搞懂synchronized(從偏向鎖到重量級鎖)

雙重檢測機制

帥地：你剛才的那種線程不安全的寫法，你知道是在什么時候調(diào)用這個方法，會出現(xiàn)線程安全問題嗎？

小秋：知道了，主要是因為，當這個實例對象還沒有被創(chuàng)建過的時候，突然同時有幾個線程來創(chuàng)建，就有可能會出現(xiàn)線程安全問題導致創(chuàng)建了不止一個實例。

但是，如果這個實例已經(jīng)被安全著創(chuàng)建了之后，以后不管有再多的線程來調(diào)用，那么都不會出現(xiàn)線程安全的問題，因為這個if語句里面的代碼永遠不會被執(zhí)行。

帥地：分析的很好，那么問題來了。當一個對象被創(chuàng)建之后，以后有線程來調(diào)用這個方法，本來可以不用進入同步塊也能保證線程安全的，可是，你把synchronized聲明在了方法名稱前，導致之后該方法的調(diào)用都會進入同步快，這樣很影響速度。

小秋：原來這樣，怪不得我看書本說，不推薦這種做法，那我改一下：

public class Singleton {
    private Singleton instance = null;
    //私有構(gòu)造函數(shù)
    private Singleton(){};
    public   Singleton getInstance() {
        synchronized (Singleton.class) {
            if (instance == null) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

帥地：小秋，你這樣其實和上面那個是幾乎一樣的，因為你把if(instance == null)這句話的判斷放在了同步塊內(nèi)，以后有線程調(diào)用這個方法，還是會每次都進入同步塊的。

其實，我們需要的是，當判斷到instance != null時，就直接把instance返回了，而不是把這個判斷放到同步塊里。

小秋：我知道怎么做了。

于是，不一會，小秋劈里啪啦就寫好了

public class Singleton {
    private Singleton instance = null;
    //私有構(gòu)造函數(shù)
    private Singleton(){};
    
    //這種是什么鬼方式？
    public   Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class){
                instance = new Singleton();
            }
        }
        return instance;
    }
}

帥地：你確定你這段代碼是線程安全的嗎？

小秋趕緊在腦子里模擬了一下當實例對象還沒有被創(chuàng)建時，有兩個進程同時進入了if(instance == null){}代碼塊中，結(jié)果發(fā)現(xiàn)這兩個對象都會成功創(chuàng)建新的對象實例。

于是，小秋趕緊在同步塊中又加了一層if判斷。

public class Singleton {
    private Singleton instance = null;
    //私有構(gòu)造函數(shù)
    private Singleton(){};
    
    //雙重檢測機制
    public   Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class){
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

帥地：腦子棟的挺快嘛，這樣子基本就能保證線程安全了。嗯，很棒。這種加鎖的方法也叫做雙重檢測機制。

解釋說明：當instance==null時，假如有兩個線程p1,p2進入了第一個if語句，之后p1進入的同步塊中，成功創(chuàng)建了對象實例，這時候論到p2進入同步塊，由于同步塊還有一層if(instance==null)的判斷，又因為此時instance != null了，所以p2無法再創(chuàng)建新的實例對象。

小秋聽到帥地夸獎自己，滿臉開心....

指令重排的搗蛋

帥地：不過，你這樣寫，還不算是絕對的線程安全，還是有可能會出現(xiàn)線程安全問題。你在仔細想想。

小秋：還會出現(xiàn)線程安全問題？(一臉懵逼)....

一陣絞盡腦汁過后....

小秋：我覺得沒啥問題啊。

帥地：好吧，你已經(jīng)寫的挺不錯了，今天就再讓你漲漲知識。

其實這個線程安全的問題，主要是因為對象的創(chuàng)建過程并非是原子性的。在創(chuàng)建的過程中，由于指令重排的影響，才導致出現(xiàn)問題的。

所謂指令重排就是改變了指令的執(zhí)行順序，例如代碼中有兩行代碼：int a = 10;int b = 20;由于虛擬機指令重排的影響，編譯后有可能順序被改變了，變成這樣：int b = 20;int a = 10;

且聽我慢慢道來：

當我們的虛擬機在執(zhí)行 instance = new Singleton這句代碼時，會被分解成以下三個動作來執(zhí)行：

memory = allocate();//1: 給對象分配內(nèi)存空間。

ctorInstance(memory);//2: 初始化對象

instance = memory; //3: 把instance變量指向剛剛分配的內(nèi)存地址。

但是，這三個動作的執(zhí)行順序并非是一成不變的，有可能經(jīng)過JVM和CPU的優(yōu)化編譯之后，這三個動作的執(zhí)行順序發(fā)生了改變，變成了這樣：

memory = allocate();//1: 給對象分配內(nèi)存空間。

instance = memory; //3: 把instance變量指向剛剛分配的內(nèi)存地址

ctorInstance(memory);//2: 初始化對象

現(xiàn)在假設instance== null,且有p1, p2兩個線程來調(diào)用這個方法。當p1執(zhí)行完1，3但還沒有執(zhí)行2時，這時instance已經(jīng)不再是null了。假如這個時候p2剛剛進入getInstance這個方法，然后執(zhí)行if(instance == null)的判斷語句，這個時候判斷的結(jié)果會是false，于是p2直接把instance給返回的。

但由于p1還沒有執(zhí)行動作2，此時的對象還沒有被初始化，但卻已經(jīng)被p2給返回了。此時，這個被返回的對象出現(xiàn)問題了。

于是，就出現(xiàn)了線程安全問題。

通過volatile來保證指令重排問題

小秋：又漲知識了。

帥地：問題的根源就是指令重排的影響，所以我們只要保證在創(chuàng)建對象的時候，不要出現(xiàn)指令重排就可以了。

所以說，我們可以把instance這個變量聲明為volatile。代碼如下：

public class Singleton {
    private volatile Singleton instance = null;
     //私有構(gòu)造函數(shù)
    private Singleton(){};
    
    public   Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class){
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

注：不清楚volatile關鍵字的可以看我之前寫的文章：
線程安全(上)--徹底搞懂volatile關鍵字

這樣，只有把instance聲明為volatile，那么虛擬機就會保證這三個動作按照順序執(zhí)行了，也就不會出現(xiàn)線程安全問題了。

小秋：哇，謝謝地哥的耐心講解呢。我要給你點個贊。

結(jié)束語

這兩次的文章都采用對話的模式來寫，之后的文章可能會更多的采用文字對話和漫畫對話的形式講，主要是因為現(xiàn)在還沒找到比較喜歡的漫畫人物，過幾天找到了，就嘗試用漫畫來講。

小伙伴們?nèi)绻泻玫娜宋锿扑]，可以通過加我為好友或者公眾號后臺發(fā)給我哦，在此感謝大家的支持。

完

獲取更多原創(chuàng)文章，可以關注下我的公眾號：苦逼的碼農(nóng)，后臺回復禮包送你一份時下熱門的資源大禮包。同時也感謝把文章介紹給更多需要的人。