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