設計模式之單例模式（二）

2019 年 12 月 25 日
筆記

上一篇我們對經典的單例模式進行了學習，並且知道了單例模式的概念，以及如何通過單執行緒去創建一個有效的單例模式，讓程式不用多次去創建實例。

但是，通過巧克力工廠的實踐，我們很想知道在多執行緒模式下，這個到底會是什麼情況呢？所以，就有了我們繼續學習的目標啦。原來單例模式，不簡單呀。

多執行緒的麻煩

首先，我們還是看下巧克力工廠經典單例的程式碼：原本在單執行緒模式下，運行的還是挺好的，工廠里那些小心翼翼的程式碼都可以去掉了；但是忽然用了多執行緒，發現還是創建了多個實例，當工廠很鬱悶。

public static ChocolateBoiler getInstance() {      if (uniqueInstance == null) {          uniqueInstance = new ChocolateBoiler(;)      }      return uniqueInstance;  }

仔細查看程式碼，你知道為什麼了嗎？這裡有兩個執行緒都要執行這段程式碼，那麼Java的JVM在進入程式碼的時候肯定會有先後順序，有沒有可能是JVM攪亂了程式碼，讓getInstance()方法內部出了問題呢？對的，就是這樣。請看下圖：

當在多執行緒環境下，執行緒1和執行緒2都進入了getInstance方法，那麼，此時通過判斷null的方式來，勢必在JVM內部，發生了交叉的事情，然後，然後你的工廠就創建了兩個實例，挺悲劇的。

處理多執行緒

熟悉Java的朋友都知道，最輕易地解決這個多執行緒的方法就是把getInstantce()變成synchronized方法，比如：

public static synchronized Singleton getInstance() {      if(uniqueInstance == null) {          uniqueInstance = new Singleton();      }      return uniqueInstance;  }

通過增加synchronized關鍵字到getInstance()方法中，每個執行緒在進入這個方法之前，需要先等候別的執行緒離開該方法，也就是說，不會有兩個執行緒可以同時進入這個方法。

但是，問題來了：我們其實只有第一次執行此方法時，才真正需要同步。換句話說，一旦設置好uniqueInstance變數，就不需要同步這個方法了。之後每次調用這個方法，如果還是同步進行的話，給資源造成了很大的浪費，也是一種累贅。

能改善多執行緒嗎？

為了符合大多數Java應用程式、我們還是需要確保單例模式能在多執行緒的情況下正常工作的。但是同步的getInstance()的做法將拖垮性能，該怎麼辦呢？

如果getInstance()的性能對應用程式不是很關鍵，就什麼都別做

沒錯，如果你的應用程式可以接受getInstance()造成的額外負擔，就忽略了吧。同步getInstance()的方法既簡單又有效。但是你必須知道，同步一個方法可能造成程式執行效率下降100倍。所以，還是得好好考慮應用場景哦。

使用「急切」創建實例，而不用延遲實例化的做法

如果應用程式總是創建並使用單例實例，或者在創建和運行時方面的負擔不太繁重，你可能想要急切（eagerly）創建此單例，比如：

public class Singleton {      // 在靜態初始化中創建單例，這段程式碼保證了執行緒安全      private static Singleton uniqueInstance = new Singleton();        private Singltton() {}        public static Singleton getInstance() {          return uniqueInstance;      }  }

利用這個做法，我們依賴JVM在載入這個類時馬上創建此唯一的單例實例。JVM保證在任何執行緒訪問uniqueInstance靜態變數之前，一定先創建。哈哈，有沒有，這就是餓漢式。

用雙重檢查加鎖，在getInstance()中減少使用同步

利用雙重檢查加鎖（double-checked locking），首先檢查是否實例已經創建了，如果尚未創建，才進行同步。這樣依賴，只有第一次會同步，這正是我們想要的。

public class Singleton {      private volatile static Singleton uniqueInstance;        private Singleton() {}        public static Singleton getInstance() {      // 檢查實例，如果不存在，就進入同步區塊，只有第一次才徹底執行這裡的程式碼          if (uniqueInstance == null) {              synchronized (Singleton.class) {      // 進去區塊後，再檢查一次，如果仍是null，才創建實例                  if (uniqueInstance == null) {                      uniqueInstance = new Singleton();                  }              }          }          return uniqueInstance;      }  }

volatile關鍵詞確保：當uniqueInstance變數被初始化成Singleton實例時，多個執行緒正確地處理uniqueInstance變數。

因為單例模式大家用的比較多，而且思路也比較清晰了，那我就在這裡把這章總結也一併附上了。

設計箱內的工具

還是按照之前的套路，總結下工具箱內新增的工具吧

OO基礎 抽象、封裝、繼承、多態
OO原則 封裝變化多用組合，少用繼承針對介面編程，不針對實現編程為交互對象之間的松耦合設計而努力依賴抽象，不要依賴具體類類應該對擴展開放，對修改關閉
OO模式 『策略模式』、『觀察者模式』、『裝飾者模式』、『抽象工廠模式』、『工廠方法模式』『單例模式』確保一個類只有一個實例，並提供全局訪問點

好的，很開心有沒有，又學會了一個設計模式，還是我們經常使用的設計模式之一。下一次，我們將學習命令模式，和大家不見不散。