大家好，我是網管，首先我問大家一個問題，你們面試的時候，面試官有沒有問過你們："你都用過什么設計模式？"，我猜多數人的回答會把單例模式，放在第一位。

我："呃… 我用過單例、工廠、觀察者，反向代理，裝飾器，哨兵"…. "，

面試官內心OS："我都沒用過這么多...反向代理是什么鬼，這小子背串了吧，不管了先就坡下驢，從頭開始問"。

面試官："用過的挺多哈，那么你能說下單例你都在什么情況下用，順便在這張紙上實現一下單例吧"。

我："當需要確保一個類型，只有一個實例時就需要使用單例模式了"。

面試官："好，那你在紙上實現一下"

十分鐘后的我："不好意思，我們之前項目里都封裝好了，我只用過，沒有機會實現，所以..."

面試官內心OS："好吧，這個面試KPI要求得進行三十分鐘，這還有小二十分鐘呢，隨便再問問，就讓他回去等信兒吧"

面試卒...

上面是我給大家編的一個場景，如有雷同，請憋住，不要在工位上笑噴～。單例模式雖然簡單，不過還是有一些說道兒的，一是應用比較廣泛，再來如果不注意容易在多線程環境下造成BUG，今天就給大家簡單說下單例模式的應用，以及用Go語言怎么正確地實現單例模式。

單例模式

上面對話里說的沒錯，單例模式是用來控制類型實例的數量的，當需要確保一個類型只有一個實例時，就需要使用單例模式。

由于要控制數量，那么可想而之只能把實例的訪問進行收口，不能誰來了都能 new 一個出來，所以單例模式還會提供一個訪問該實例的全局端口，一般都會命名個 GetInstance之類的函數用作實例訪問的端口。

又因為在什么時間創建出實例，單例模式又可以分裂出餓漢模式? 和 懶漢模式，前者適用于在程序早期初始化時創建已經確定需要加載的類型實例，比如項目的數據庫實例。后者其實就是延遲加載的模式，適合程序執行過程中條件成立才創建加載的類型實例。

下面我們用 Go 代碼把這兩種單例模式實現一下。

餓漢模式

這個模式用 Go 語言實現時，借助 Go 的init函數來實現特別方便

如果你想了解 Go init 函數的方方面面，可以看以前的老文章Go語言init函數你必須記住的六個特征

下面用單例模式返回數據庫連接實例，相信你們在項目里都見過類似代碼。

package dao
// 餓漢式單例
// 注意定義非導出類型
type  databaseConn struct{
  ...
}

var dbConn *databaseConn

func init() {
  dbConn = &databaseConn{}
}

// GetInstance 獲取實例
func Db() *databaseConn {
 return dbConn
}

這里初始化數據庫的細節咱們就不多費文筆了，實際情況肯定是從配置中心加載下來數據庫連接配置再實例化數據庫的連接對象。這里有人可能會有個問題，你這一個程序進程就只有一個數據連接實例，那這么多請求都用一個數據庫連接行嗎？

誒，這個是對數據庫連接的抽象呀，這個實例會維護一個連接池，那里才是真正去請求數據庫用的連接。是不是有點暈，有點暈去看看你們項目里這塊的代碼。一般會看到初始化實例時，讓你設置最大連接數、閑置連接數和存活時間這樣的連接池配置。

懶漢模式

懶漢模式--通俗點說就是延遲加載，不過這塊特別注意，要考慮并發環境下，你的判斷實例是否已經創建時，是不是用的當前讀。在一些教設計模式的教程里，一般這種情況下會舉一個例子--用 Java 雙重鎖實現線程安全的單例模式，雙重鎖指的是volatile和synchronized。

class Singleton {
    private volatile static Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}

上面這個例子里，如果不給instance?屬性加上 volatile?修飾符，那么雖說創建的過程已經用synchronized?給類加了鎖，但是有可能讀到的instance?是線程緩存是滯后的，有可能屬性此時已經被其他線程初始化了，所以就必須加上volatile保證當前讀（讀主存里屬性的狀態）。

那么 Go 里邊沒有volatile?這種機制，我們該怎么辦呢？聰明的你一定能想得出，我們定義一個實例的狀態變量，然后用原子操作atomic.Load、atomic.Store去讀寫這個狀態變量，不就是實現了嗎？像下面這樣：

如果 Go 原子操作你還不熟，請看老文章Golang 五種原子性操作的用法詳解

import "sync"
import "sync/atomic"

var initialized uint32

type singleton struct {
  ...
}

func GetInstance() *singleton {

    if atomic.LoadUInt32(&initialized) == 1 {  // 原子操作 
      return instance
   }

    mu.Lock()
    defer mu.Unlock()

    if initialized == 0 {
         instance = &singleton{}
         atomic.StoreUint32(&initialized, 1)
    }

    return instance
}

確實，相當于把上面 Java 的例子翻譯成用 Go 實現了，不過還有另外一種更Go? native 的寫法，比這種寫法更簡練。如果用 Go 更慣用的寫法，我們可以借助其sync?庫中自帶的并發同步原語Once來實現：

package singleton

import (
    "sync"
)

type singleton struct {}

var instance *singleton
var once sync.Once

func GetInstance() *singleton {
    once.Do(func() {
        instance = &singleton{}
    })
    return instance
}

關于sync.One ?的使用和其實現原理…我發現我的Go 并發編程系列?里沒單獨寫Once?這個原語，可能是覺得太簡單了吧，后期抽空補上吧… 不過只是原理分析沒寫，怎么應用在Go語言sync包的應用詳解里也能找到。

總結

這篇文章其實是把單例模式的應用，和Go的單例模式版本怎么實現給大家說了一下，現在教程大部分都是用 Java 講設計模式的，雖然我們可以直接翻譯，不過有的時候 Go 有些更native 的實現方式，讓實現更簡約一些。