C++的單例模式為什么不直接全部使用static，而是非要實(shí)例化一個(gè)對象？

通過getInstance()函數(shù)獲取單例對象，這種模式的關(guān)鍵之處不是在于強(qiáng)迫你用函數(shù)來獲取對象。關(guān)鍵之處是讓static對象定義在函數(shù)內(nèi)部，變成局部static變量。

看下這種實(shí)現(xiàn)方式的經(jīng)典demo：

class Singleton {
public:
    static Singleton& getInstance() {
        static Singleton inst;
        return inst;
    }
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    // 其他數(shù)據(jù)函數(shù)
    // ...

private:
    Singleton() { ... }
    // 其他數(shù)據(jù)成員
    // ...
};

學(xué)名是：Meyers' Singleton。沒錯(cuò)，也就是說這是Scott Meyers最早提出來的C++單例模式的推薦寫法。

注意：這種單例寫法需要C++11。因?yàn)槭菑腃++11標(biāo)準(zhǔn)才開始規(guī)定 static變量是線程安全的。也就是說無需我們自己寫加鎖保護(hù)的代碼，編譯器能夠幫我們做到。

所以C++程序員們不要在讀完Java單例模式的資料之后，在C++程序中寫double check或volatile了！

如果是把 static對象定義成 Singleton的私有static成員變量，然后getInstance()去返回這個(gè)成員即：

class Singleton {
public:
    static Singleton& getInstance() {
        return inst;
    }
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    // 其他數(shù)據(jù)函數(shù)
    // ...

private:
    Singleton() { ... }
    static Singleton inst;
    // 其他數(shù)據(jù)成員
    // ...
};
Singleton Singleton::inst;

雖然它也是 先getInstance()再訪問，但這種不是Meyers' Singleton！

那么為什么Meyers推薦的是第一種的呢？

原因是這解決了一類重要問題，那就是static變量的初始化順序的問題。

C++只能保證在同一個(gè)文件中聲明的static變量的初始化順序與其變量聲明的順序一致。但是不能保證不同的文件中的static變量的初始化順序。

然后對于單例模式而言，不同的單例對象之間進(jìn)行調(diào)用也是常見的場景。比如我有一個(gè)單例，存儲(chǔ)了程序啟動(dòng)時(shí)加載的配置文件的內(nèi)容。另外有一個(gè)單例，掌管著一個(gè)全局唯一的日志管理器。在日志管理初始化的時(shí)候，要通過配置文件的單例對象來獲取到某個(gè)配置項(xiàng)，實(shí)現(xiàn)日志打印。

這時(shí)候兩個(gè)單例在不同文件中各自實(shí)現(xiàn)，很有可能在日志管理器的單例使用配置文件單例的時(shí)候，配置文件的單例對象是沒有被初始化的。這個(gè)未初始化可能產(chǎn)生的風(fēng)險(xiǎn)指的是C++變量的未初始化，而不是說配置文件未加載的之類業(yè)務(wù)邏輯上的未初始化導(dǎo)致的問題。

而Meyers' Singleton寫法中，單例對象是第一次訪問的時(shí)候（也就是第一次調(diào)用getInstance()函數(shù)的時(shí)候）才初始化的，但也是恰恰因?yàn)槿绱耍蚨鼙ＷC如果沒有初始化，在該函數(shù)調(diào)用的時(shí)候，是能完成初始化的。所以先getInstance()再訪問 這種形式的單例 其關(guān)鍵并不是在于這個(gè)形式。而是在于其內(nèi)容，局部static變量能保證通過函數(shù)來獲取static變量的時(shí)候，該函數(shù)返回的對象是肯定完成了初始化的！

講到這，我們對Meyers' Singleton的盲目鼓吹也需冷靜一下，因?yàn)镃++同樣能保證所有文件內(nèi)（非函數(shù)內(nèi)）的static變量在main()函數(shù)開始運(yùn)行之后肯定是都能做完初始化的。所以如果你是在main()函數(shù)運(yùn)行之后，用日志管理器的單例訪問配置文件的單例，那么其實(shí)也是沒有問題的… 這就引出Meyers' Singleton的第二個(gè)優(yōu)勢，那就是當(dāng)產(chǎn)生繼承的時(shí)候。

如果出現(xiàn)繼承，這種寫法中：

class Singleton {
public:
    static void on() {Singleton::isOn = true;}
    static void off() {Singleton::isOn = false;}
    static bool state() {return Singleton::isOn;}
private:
    static bool isOn;
};

class Monitor: public Singleton {
public:
    static void addBrightness(int val) { brightness += val;}
    static void subBrightness(int val) { brightness -= val;}
    static int getBrightness() { return brightness;}

private:
    static int brightness;
};

如果有子類繼承這一父類，來拓展成新的子類，比如Monitor顯示器類有開關(guān)狀態(tài)，同時(shí)擴(kuò)展了一個(gè)亮度的成員。但是父子類的static成員變量是共享的，其isOn成員會(huì)有問題。

好吧，如果你說你的單例完全不會(huì)出現(xiàn)繼承的情況，是不是就不需要寫成Meyers' Singleton？我只想說，如果你一定要強(qiáng)加這么多限定的話，那么這種設(shè)計(jì)模式的討論本身就沒有意義。就很像是在說：我自己能夠保證每個(gè)new出來的指針我都能delete掉它，所以我不需要RAII……

總結(jié)：

所謂設(shè)計(jì)模式（design pattern）、慣用法（idiom）這種老程序員的經(jīng)驗(yàn)之談都是讓你在大多數(shù)情況下，即使你不懂其奧秘，但凡遵守了，就能避免掉很多潛在的問題。盡管這種問題并不能百分百發(fā)生。所以這倒沒必要去抬杠。