開場
前段時間我在知乎回答了這樣一個問題：
為什么C++單例模式不能直接全部使用 static變量和 static函數(shù)呢？如果全部使用 static的話，是不是也不會有多線程的問題了？而且“類型::方法”的訪問方式比起先getInstance()再訪問難道不是更加簡單清晰嗎？
（還是說是為了附和 “單例” 這樣一個字面上的意思）
//大概這個樣子
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;
};
這可能是很多C++學(xué)習(xí)者都會有的疑惑，下面是我的回答。
正文
通過getInstance()函數(shù)獲取單例對象，這種模式的關(guān)鍵之處不是在于強(qiáng)迫你用函數(shù)來獲取對象。關(guān)鍵之處是讓static對象定義在函數(shù)內(nèi)部，變成局部static變量。看下這種實現(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。沒錯，也就是說這是Scott Meyers最早提出來的C++單例模式的推薦寫法。
???? 注意這種單例寫法需要C++11。因為是從C++11標(biāo)準(zhǔn)才開始規(guī)定 static變量是線程安全的。也就是說無需我們自己寫加鎖保護(hù)的代碼，編譯器能夠幫我們做到。
? 所以C++程序員們不要在讀完Java單例模式的資料之后，在C++程序中寫double check或volatile了！
如果是把 static對象定義成 Singleton的私有static成員變量，然后getInstance()去返回這個成員即：
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++只能保證在同一個文件中聲明的static變量的初始化順序與其變量聲明的順序一致。但是不能保證不同的文件中的static變量的初始化順序。
然后對于單例模式而言，不同的單例對象之間進(jìn)行調(diào)用也是常見的場景。比如我有一個單例，存儲了程序啟動時加載的配置文件的內(nèi)容。另外有一個單例，掌管著一個全局唯一的日志管理器。在日志管理初始化的時候，要通過配置文件的單例對象來獲取到某個配置項，實現(xiàn)日志打印。
這時候兩個單例在不同文件中各自實現(xiàn)，很有可能在日志管理器的單例使用配置文件單例的時候，配置文件的單例對象是沒有被初始化的。這個未初始化可能產(chǎn)生的風(fēng)險指的是C++變量的未初始化，而不是說配置文件未加載的之類業(yè)務(wù)邏輯上的未初始化導(dǎo)致的問題。
而Meyers' Singleton寫法中，單例對象是第一次訪問的時候（也就是第一次調(diào)用getInstance()函數(shù)的時候）才初始化的，但也是恰恰因為如此，因而能保證如果沒有初始化，在該函數(shù)調(diào)用的時候，是能完成初始化的。所以先getInstance()再訪問 這種形式的單例 其關(guān)鍵并不是在于這個形式。而是在于其內(nèi)容，局部static變量能保證通過函數(shù)來獲取static變量的時候，該函數(shù)返回的對象是肯定完成了初始化的！
講到這，我們對Meyers' Singleton的盲目鼓吹也需冷靜一下，因為C++同樣能保證所有文件內(nèi)（非函數(shù)內(nèi)）的static變量在main()函數(shù)開始運(yùn)行之后肯定是都能做完初始化的。所以如果你是在main()函數(shù)運(yùn)行之后，用日志管理器的單例訪問配置文件的單例，那么其實也是沒有問題的… 這就引出Meyers' Singleton的第二個優(yōu)勢，那就是當(dāng)產(chǎn)生繼承的時候。如果出現(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)，同時擴(kuò)展了一個亮度的成員。但是父子類的static成員變量是共享的，其isOn成員會有問題。
好吧，如果你說你的單例完全不會出現(xiàn)繼承的情況，是不是就不需要寫成Meyers' Singleton？我只想說，如果你一定要強(qiáng)加這么多限定的話，那么這種設(shè)計模式的討論本身就沒有意義。就很像是在說：我自己能夠保證每個new出來的指針我都能delete掉它，所以我不需要RAII……
???? 所謂設(shè)計模式（design pattern）、慣用法（idiom）這種老程序員的經(jīng)驗之談都是讓你在大多數(shù)情況下，即使你不懂其奧秘，但凡遵守了，就能避免掉很多潛在的問題。盡管這種問題并不能百分百發(fā)生。所以這倒沒必要去抬杠。