前言

單例模式應該是我們最熟悉的模式了，如果說要隨便抓一個程式員，讓他說一說最熟悉的集中設計模式，我想肯定有單例模式，

我們這節就全面的來講解一下單例模式，

為什么要用單例模式

單例模式理解起來非常簡單，在一個系統中，一個類只允許創建一個物件，那這個類就是單例類，這種設計模式就叫做單例設計模式，

為什么需要單例模式呢？首先我們得熟知他的運用場景，就是某個類比如工廠類，配置類，我們系統中只需要一份得，無需多次重復創建的類，我們就可以用單例模式，

單例模式的實作方式

餓漢式

餓漢式的實作方式比較簡單，在類加載的時候，instance靜態實體就已經創建并初始化好了，所以，instance實體的創建程序是執行緒安全的，不過，這樣的實作方式不支持延遲加載（在真正使用到的時候，再創建），代碼如下：

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static final IdGenerator instance = new IdGenerator();
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

IdGenerator類是被靜態變數修飾并且是直接實體化的，所以當我們呼叫getInstance（）方法，jvm會加載IdGenerator，（加載的程序中，jvm會經歷加載->驗證->準備->決議->初始化，該程序是天然加鎖的），初始化完成以后成員變數instance就指向了IdGenerator實體物件，又因為IdGenerator的構造方法是private修飾的，所以通過該方法我們就實作了餓漢式的單例模式，

懶漢式

有餓漢式，就有對應的懶漢式，懶漢式相對于餓漢式的優勢是支持延遲加載，具體代碼如下：

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static IdGenerator instance;
  private IdGenerator() {}
  public static synchronized IdGenerator getInstance() {
    if (instance == null) {
      instance = new IdGenerator();
    }
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

不過懶漢式的缺點也很明顯，我們給getInstance（）方法加了一把大鎖，導致這個函式的并發度很低，量化一下的話，并發度是1，也就相當于串行操作了，而這個函式實在單例使用期間，一直會被呼叫，如果這個單例類偶爾會被用到，那這種實作方式還可以接受，但是，如果頻繁地使用到，那頻繁的加鎖和釋放鎖以及并發度低等問題，會導致性能很差，

雙重檢查鎖

餓漢式不支持延遲加載，懶漢式有性能問題，那么有沒有一種及支持延遲加載又支持高并發的單例實作方式呢？

有的，雙重檢查鎖登場~我們來看如下代碼：

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private static volatile IdGenerator instance;
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    if (instance == null) {
      synchronized(IdGenerator.class) { // 此處為類級別的鎖
        if (instance == null) {
          instance = new IdGenerator();
        }
      }
    }
    return instance;
  }
  public long getId() { 
    return id.incrementAndGet();
  }
}

這種實作方式中，只要instance被創建之后，即使再呼叫geiInstance（）函式也不會再進入加鎖邏輯中，所以，這種方式實作解決了懶漢式并發度低的問題，

注意，我們給instance成員變數加上了volatile的關鍵字，為什么呢？

重排序可能會讓該代碼出現問題，因為我們new一個物件的順序是 開辟記憶體空間->創建物件->指向該記憶體空間，如果我們不加上volatile關鍵字，就可能會發生重排序，變成 開辟記憶體空間->指向該記憶體空間->創建物件，

大家想一想，是不是就有可能導致IdGenerator物件被new出來，并且賦值給instance之后，并沒有來得及初始化，就被另一個執行緒使用了，

靜態內部類

我們再來看一種比雙重檢查鎖更加簡單的實作方法，那就是利用java的靜態內部類，它有點類似餓漢式，但又能做到延遲加載，我們來看看它的實作:

public class IdGenerator { 
  private AtomicLong id = new AtomicLong(0);
  private IdGenerator() {}

  private static class SingletonHolder{
    private static final IdGenerator instance = new IdGenerator();
  }
  
  public static IdGenerator getInstance() {
    return SingletonHolder.instance;
  }
 
  public long getId() { 
    return id.incrementAndGet();
  }
}

SingletonHolder是一個靜態內部類，當外部類IdGenerator被加載的時候，并不會創建SingletonHolder實體物件，只有當呼叫getInstance()方法的時候，SingletonHolder才會被加載，這個時候才會創建instance，instance的唯一性、創建程序的執行緒安全性，都由JVM來保證，所以，這種實作方式既保證了執行緒安全，又能做到延遲加載，

列舉

我們再來看最后一種實作方式，列舉，

這種方式通過java列舉型別本身的特性，保證了實體創建的執行緒安全性和實體的唯一性，具體代碼如下：

public enum IdGenerator {
  INSTANCE;
  private AtomicLong id = new AtomicLong(0);
 
  public long getId() { 
    return id.incrementAndGet();
  }
}

總結

單例模式是設計模式中比較簡單一種，也是每個程式員必須掌握的設計模式，五種實作方式都應該掌握，

我們最后再討論一個問題，延遲加載的好壞？

其實就我而言，我反而覺得餓漢式是最簡單，也是相對最優的實作方式，為什么呢？其實大家好像有一個共識，提前初始化是一種浪費資源的行為，最好的方式應該是再用到的時候再去初始化，但是仔細想一想真的是這樣的嗎?

我們大部分同學作為業務性開發，而單例模式是創建好就一直存在我們系統中，如果說創建的程序中發生資源不夠，或者例外的時候，我們是希望在系統啟動的時候就發現還是在系統運行到一半的時候呢？

肯定是系統一創建我們就發現問題，就能立即去修復，這樣也能避免程式在運行一段時間后，突然因為初始化這個實體占用資源過多，導致系統奔潰，影響系統的可用性，所以我的建議還是作為業務性開發，盡量還是使用餓漢式~

如果你有什么不同的想法，歡迎留言~

標籤：設計模式

上一篇：Strategy Pattern(策略模式）

下一篇：設計模式(13) 職責鏈模式