上次帥地問的問題，讓小秋學習了不少。這幾天小秋剛好學習了一些設計模式的知識，這不，又跑去找帥地探討一些問題了。
粗糙的同步
小秋：地哥，上次你問的問題，讓我收獲頗多，這些天我大致研究了下設計模式，帥地有什么指教的嗎？
帥地：小子，行啊。那我再考考你得了。
此刻小秋聚精會神著等帥地又會拋出哪些問題.....
帥地：學過單例模式吧？單例模式有多種寫法，寫一種出來看看。
小秋：好啊，聽說單例模式是面試中問的最多的一種模式，對于單例模式的幾種的寫法，我可以相當熟練哦（有點得意）。
于是，小秋甩手就寫了一種懶漢模式的代碼出來
public class Singleton {
private Singleton instance = null;
//私有構造函數
private Singleton(){};
public Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
懶漢模式：就是等到有線程調用getInstance這個方法時，才來創建對象實例。與懶漢模式相反的是餓漢模式，下篇會講到。
帥地：夠熟練的你，不過你這段代碼并非線程安全的，怎么辦？
小秋：嘿嘿，簡單，看我的。
public class Singleton {
private Singleton instance = null;
//私有構造函數
private Singleton(){};
//多了個synchronized關鍵字
public synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
注：不清楚synchronized關鍵字的可以看我之前寫的文章：線程安全(上)--徹底搞懂synchronized(從偏向鎖到重量級鎖)
雙重檢測機制
帥地：你剛才的那種線程不安全的寫法，你知道是在什么時候調用這個方法，會出現線程安全問題嗎？
小秋：知道了，主要是因為，當這個實例對象還沒有被創建過的時候，突然同時有幾個線程來創建，就有可能會出現線程安全問題導致創建了不止一個實例。
但是，如果這個實例已經被安全著創建了之后，以后不管有再多的線程來調用，那么都不會出現線程安全的問題，因為這個if語句里面的代碼永遠不會被執行。
帥地：分析的很好，那么問題來了。當一個對象被創建之后，以后有線程來調用這個方法，本來可以不用進入同步塊也能保證線程安全的，可是，你把synchronized聲明在了方法名稱前，導致之后該方法的調用都會進入同步快，這樣很影響速度。
小秋：原來這樣，怪不得我看書本說，不推薦這種做法，那我改一下：
public class Singleton {
private Singleton instance = null;
//私有構造函數
private Singleton(){};
public Singleton getInstance() {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
return instance;
}
}
帥地：小秋，你這樣其實和上面那個是幾乎一樣的，因為你把if(instance == null)這句話的判斷放在了同步塊內，以后有線程調用這個方法，還是會每次都進入同步塊的。
其實，我們需要的是，當判斷到instance != null時，就直接把instance返回了，而不是把這個判斷放到同步塊里。
小秋：我知道怎么做了。
于是，不一會，小秋劈里啪啦就寫好了
public class Singleton {
private Singleton instance = null;
//私有構造函數
private Singleton(){};
//這種是什么鬼方式？
public Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
instance = new Singleton();
}
}
return instance;
}
}
帥地：你確定你這段代碼是線程安全的嗎？
小秋趕緊在腦子里模擬了一下當實例對象還沒有被創建時，有兩個進程同時進入了if(instance == null){}代碼塊中，結果發現這兩個對象都會成功創建新的對象實例。
于是，小秋趕緊在同步塊中又加了一層if判斷。
public class Singleton {
private Singleton instance = null;
//私有構造函數
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進入的同步塊中，成功創建了對象實例，這時候論到p2進入同步塊，由于同步塊還有一層if(instance==null)的判斷，又因為此時instance != null了，所以p2無法再創建新的實例對象。
小秋聽到帥地夸獎自己，滿臉開心....
指令重排的搗蛋
帥地：不過，你這樣寫，還不算是絕對的線程安全，還是有可能會出現線程安全問題。你在仔細想想。
小秋：還會出現線程安全問題？(一臉懵逼)....
一陣絞盡腦汁過后....
小秋：我覺得沒啥問題啊。
帥地：好吧，你已經寫的挺不錯了，今天就再讓你漲漲知識。
其實這個線程安全的問題，主要是因為對象的創建過程并非是原子性的。在創建的過程中，由于指令重排的影響，才導致出現問題的。
所謂指令重排就是改變了指令的執行順序，例如代碼中有兩行代碼：int a = 10;int b = 20;由于虛擬機指令重排的影響，編譯后有可能順序被改變了，變成這樣：int b = 20;int a = 10;
且聽我慢慢道來：
當我們的虛擬機在執行 instance = new Singleton這句代碼時，會被分解成以下三個動作來執行：
memory = allocate();//1: 給對象分配內存空間。
ctorInstance(memory);//2: 初始化對象
instance = memory; //3: 把instance變量指向剛剛分配的內存地址。
但是，這三個動作的執行順序并非是一成不變的，有可能經過JVM和CPU的優化編譯之后，這三個動作的執行順序發生了改變，變成了這樣：
memory = allocate();//1: 給對象分配內存空間。
instance = memory; //3: 把instance變量指向剛剛分配的內存地址
ctorInstance(memory);//2: 初始化對象
現在假設instance== null,且有p1, p2兩個線程來調用這個方法。當p1執行完1，3但還沒有執行2時，這時instance已經不再是null了。假如這個時候p2剛剛進入getInstance這個方法，然后執行if(instance == null)的判斷語句，這個時候判斷的結果會是false，于是p2直接把instance給返回的。
但由于p1還沒有執行動作2，此時的對象還沒有被初始化，但卻已經被p2給返回了。此時，這個被返回的對象出現問題了。
于是，就出現了線程安全問題。
通過volatile來保證指令重排問題
小秋：又漲知識了。
帥地：問題的根源就是指令重排的影響，所以我們只要保證在創建對象的時候，不要出現指令重排就可以了。
所以說，我們可以把instance這個變量聲明為volatile。代碼如下：
public class Singleton {
private volatile Singleton instance = null;
//私有構造函數
private Singleton(){};
public Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
注：不清楚volatile關鍵字的可以看我之前寫的文章：
線程安全(上)--徹底搞懂volatile關鍵字
這樣，只有把instance聲明為volatile，那么虛擬機就會保證這三個動作按照順序執行了，也就不會出現線程安全問題了。
小秋：哇，謝謝地哥的耐心講解呢。我要給你點個贊。
結束語
這兩次的文章都采用對話的模式來寫，之后的文章可能會更多的采用文字對話和漫畫對話的形式講，主要是因為現在還沒找到比較喜歡的漫畫人物，過幾天找到了，就嘗試用漫畫來講。
小伙伴們如果有好的人物推薦，可以通過加我為好友或者公眾號后臺發給我哦，在此感謝大家的支持。
完
獲取更多原創文章，可以關注下我的公眾號：苦逼的碼農，后臺回復禮包送你一份時下熱門的資源大禮包。同時也感謝把文章介紹給更多需要的人。
