開場

前段時(shí)間在知乎回答了這樣一個(gè)問題：

為什么C++單例模式不能直接全部使用 static變量和 static函數(shù)呢？如果全部使用 static的話，是不是也不會有多線程的問題了？而且“類型::方法”的訪問方式比起先getInstance()再訪問難道不是更加簡單清晰嗎？

（還是說是為了附和 “單例” 這樣一個(gè)字面上的意思）

//大概這個(gè)樣子
classSingleton{
public:
staticvoidon(){Singleton::isOn=true;}
staticvoidoff(){Singleton::isOn=false;}
staticboolstate(){returnSingleton::isOn;}
private:
staticboolisOn;
};

這可能是很多C++學(xué)習(xí)者都會有的疑惑，下面是我的回答。

正文

通過getInstance()函數(shù)獲取單例對象，這種模式的關(guān)鍵之處不是在于強(qiáng)迫你用函數(shù)來獲取對象。關(guān)鍵之處是讓static對象定義在函數(shù)內(nèi)部，變成局部static變量?？聪逻@種實(shí)現(xiàn)方式的經(jīng)典demo：

classSingleton{
public:
staticSingleton&getInstance(){
staticSingletoninst;
returninst;
}
Singleton(constSingleton&)=delete;
Singleton&operator=(constSingleton&)=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è)成員即：

classSingleton{
public:
staticSingleton&getInstance(){
returninst;
}
Singleton(constSingleton&)=delete;
Singleton&operator=(constSingleton&)=delete;

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

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

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

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

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

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

然后對于單例模式而言，不同的單例對象之間進(jìn)行調(diào)用也是常見的場景。比如我有一個(gè)單例，存儲了程序啟動(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)槿绱?，因而能保證如果沒有初始化，在該函數(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)繼承，這種寫法中：

classSingleton{
public:
staticvoidon(){Singleton::isOn=true;}
staticvoidoff(){Singleton::isOn=false;}
staticboolstate(){returnSingleton::isOn;}
private:
staticboolisOn;
};

classMonitor:publicSingleton{
public:
staticvoidaddBrightness(intval){brightness+=val;}
staticvoidsubBrightness(intval){brightness-=val;}
staticintgetBrightness(){returnbrightness;}

private:
staticintbrightness;
};

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

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

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

審核編輯 ：李倩