開場

前段時間在知乎回答了這樣一個問題：

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

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

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

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

正文

通過getInstance()函數獲取單例對象，這種模式的關鍵之處不是在于強迫你用函數來獲取對象。關鍵之處是讓static對象定義在函數內部，變成局部static變量。看下這種實現方式的經典demo：

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

//其他數據函數
//...

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

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

注意這種單例寫法需要C++11。因為是從C++11標準才開始規定 static變量是線程安全的。也就是說無需我們自己寫加鎖保護的代碼，編譯器能夠幫我們做到。

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

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

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

//其他數據函數
//...

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

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

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

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

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

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

這時候兩個單例在不同文件中各自實現，很有可能在日志管理器的單例使用配置文件單例的時候，配置文件的單例對象是沒有被初始化的。這個未初始化可能產生的風險指的是C++變量的未初始化，而不是說配置文件未加載的之類業務邏輯上的未初始化導致的問題。

而Meyers' Singleton寫法中，單例對象是第一次訪問的時候（也就是第一次調用getInstance()函數的時候）才初始化的，但也是恰恰因為如此，因而能保證如果沒有初始化，在該函數調用的時候，是能完成初始化的。所以先getInstance()再訪問 這種形式的單例 其關鍵并不是在于這個形式。而是在于其內容，局部static變量能保證通過函數來獲取static變量的時候，該函數返回的對象是肯定完成了初始化的！

講到這，我們對Meyers' Singleton的盲目鼓吹也需冷靜一下，因為C++同樣能保證所有文件內（非函數內）的static變量在main()函數開始運行之后肯定是都能做完初始化的。所以如果你是在main()函數運行之后，用日志管理器的單例訪問配置文件的單例，那么其實也是沒有問題的… 這就引出Meyers' Singleton的第二個優勢，那就是當產生繼承的時候。如果出現繼承，這種寫法中：

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顯示器類有開關狀態，同時擴展了一個亮度的成員。但是父子類的static成員變量是共享的，其isOn成員會有問題。

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

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

審核編輯 ：李倩