您好,登錄后才能下訂單哦!
這篇文章主要介紹“Singleton模式創(chuàng)建、多線程與銷毀的方法是什么”,在日常操作中,相信很多人在Singleton模式創(chuàng)建、多線程與銷毀的方法是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對(duì)大家解答”Singleton模式創(chuàng)建、多線程與銷毀的方法是什么”的疑惑有所幫助!接下來,請(qǐng)跟著小編一起來學(xué)習(xí)吧!
1 Singleton創(chuàng)建
1.1 GOF Singleton
在GOF著作中對(duì)Singleton模式的實(shí)現(xiàn)方式如下:
/*解一*/ class Singleton { public: static Singleton *Instance(){ //1 if( !m_pInstatnce) //2 m_pInstance = new Singleton;//3 return m_pInstance; //4 } private: static Singleton *m_pInstatnce; //5 private: Singleton(); //6 Singleton(const Singleton&); //7 Singleton& operator=(const Singleton&); //8 ~Singleton(); //9 } Singleton *Singleton:m_pInstatnce = NULL; //10
在上面的解決方案中,我們只在需要調(diào)用時(shí),才產(chǎn)生一個(gè)Singleton的對(duì)象。這樣帶來的好處是,如果該對(duì)象產(chǎn)生帶來的結(jié)果很昂貴,但不經(jīng)常用到時(shí),是一種非常好的策略。但如果該Instance被頻繁調(diào)用,那么就有人覺得Instance中的判斷降低了效率(雖然只是一個(gè)判斷語句^_^),那么我們就把第5條語句該為
static Singleton m_Instatnce;
如此一來,在Instatnce直接返回&m_Instance,而不用做任何判斷,效率也高了。(是不是呢?)
這樣修改后,我們將帶來災(zāi)難性的后果:
1:首先有可能編譯器這關(guān)就沒法通過,說m_Instance該外部變量無法解決(visural C++6.0)
error LNK2001: unresolved external symbol "private: static class Singleton Singleton::m_Instance" (?m_Instance@Singleton@@0V1@A)
2:如果編譯器這關(guān)通過了就沒問題了么?答案是否定的。
***是不管Instance是否用到,該靜態(tài)變量對(duì)象在編譯器編譯時(shí)就產(chǎn)生了,即資源消耗是不可避免的;
第二是無法確保編譯器一定先將m_Instance初始化。所以Instance的調(diào)用有可能傳回一個(gè)尚沒構(gòu)造的Singleton對(duì)象。這也意味著你無法保證任何外部對(duì)象所使用的m_Instance是一個(gè)被正確初始化的對(duì)象。
1.2 Meyers Singleton
我們?nèi)绾谓鉀Q這個(gè)問題呢,實(shí)際上很簡單。一種非常優(yōu)雅的做法由Scott Meyers***提出,故也稱為Meyers Singleton。它依賴編譯器的神奇技巧。即函數(shù)內(nèi)的static對(duì)象只在該函數(shù)***次執(zhí)行時(shí)才初始化(請(qǐng)注意不是static常量)。
/*解二*/ class Singleton { public: static Singleton *Instance(){ //1 static Singleton sInstance; //2 return &sInstance; //3 } private: Singleton(); //4 Singleton(const Singleton&); //5 Singleton& operator=(const Singleton&); //6 ~Singleton(); //7 }
解二在Instance中定義了一個(gè)Static的Singleton對(duì)象,來解決Instance中初始化的問題,也很順利的解決了定義Static成員對(duì)象帶來的問題。
請(qǐng)注意,解二在VC6中不能編譯通過,將有以下的錯(cuò)誤:
error C2248: 'Singleton::~Singleton' : cannot access private member declared in class 'Singleton' e:\work\q\a.h(81) : see declaration of 'Singleton::~Singleton'
產(chǎn)生該問題的錯(cuò)誤原因是什么呢(請(qǐng)仔細(xì)思考^_^)
原因在于在產(chǎn)生static Singleton對(duì)象后,編譯器會(huì)自動(dòng)產(chǎn)生一個(gè)銷毀函數(shù)__DestroySingleton,然后調(diào)用atexit()注冊,在程序退出時(shí)執(zhí)行__DestroySingleton。但由于Singleton的析構(gòu)函數(shù)是private,所以會(huì)產(chǎn)生訪問錯(cuò)誤。(應(yīng)該在以后的編譯器中修改了該BUG)
1.3 Singleton改進(jìn)
讓Instance傳回引用(reference)。如果傳回指針,調(diào)用端有可能講它delete調(diào)。
1.4 Singleton注意之點(diǎn)
在上面的解法中,請(qǐng)注意對(duì)構(gòu)造函數(shù)和析構(gòu)函數(shù)的處理,有何好處(請(qǐng)自己理解,俺懶病又犯了)。
2 多線程
在解一中,如果我們運(yùn)行在多線程的環(huán)境中,該方案是***的么,將會(huì)有什么后果呢?
后果就是會(huì)造成內(nèi)存泄漏,并且有可能前后獲取的Singleton對(duì)象不一樣(原因請(qǐng)自己思考,后面有解答)。
為了解決這個(gè)問題,將解一的Instance改為如下:
Singleton& Singleton::Instance(){ Lock(m_mutex); //含義為獲取互斥量 //1 If( !m_pInstance ){ //2 m_pInstance = new Singleton; //3 } UnLock(m_mutex); //4 return *m_pInstance; //5 }
此種方法將解決解一運(yùn)行在多線程環(huán)境下內(nèi)存泄漏的問題,但帶來的結(jié)果是,當(dāng)m_mutex被鎖定時(shí),其它試圖鎖定m_mutex的線程都將必須等等。并且每次執(zhí)行鎖操作其付出的代價(jià)極大,亦即是這種方案的解決辦法并不吸引人。
那么我們將上面的代碼改為如下方式:
Singleton& Singleton::Instance(){ If( !m_pInstance ){ //1 Lock(m_mutex); //含義為獲取互斥量 //2 m_pInstance = new Singleton; //3 UnLock(m_mutex); //4 } return *m_pInstance; //5 }
這樣修改的結(jié)果沒有問題了么?NO!!!!該方案帶來的結(jié)果同解一,原因也一樣,都將造成內(nèi)存泄漏。此時(shí)“雙檢測鎖定”模式就粉墨登場了。
由Doug Schmidt和Tim Harrison提出了“雙檢測鎖定”(Double-Checked Locking)模式來解決multithread singletons問題。
Singleton& Singleton::Instance(){ If( !m_pInstance ){ //1 Lock(m_mutex); //含義為獲取互斥量 //2 If(!m_pInstance) //3 m_pInstance = new Singleton; //4 UnLock(m_mutex); //5 } return *m_pInstance; //6 }
請(qǐng)看上面的第三句,這句話是不是具有化腐朽為神奇的力量啊 ^_^
上面的方案就***了么?;卮疬€是NO!!!(各位看官是否已經(jīng)郁悶了啊,這不是玩我?。空?qǐng)耐心點(diǎn),聽我細(xì)細(xì)到來^_^)
如果在RISC機(jī)器上編譯器有可能將上面的代碼優(yōu)化,在鎖定m_mutex前執(zhí)行第3句。這是完全有可能的,因?yàn)?**句和第3句一樣,根據(jù)代碼優(yōu)化原則是可以這樣處理的。這樣一來,我們引以為自豪的“雙檢測鎖定”居然沒有起作用( L)
怎么辦?解決唄。怎么解決?簡單,我們在m_pInstance前面加一個(gè)修飾符就可以了。什么修飾符呢?……
àvolatile(簡單吧)
那么我們完整的解法如下:
/*解三*/ class Singleton { public: static Singleton &Instance(){ //1 if( !m_pInstatnce){ //2 Lock(m_mutex) //3 If( !m_pInstance ) //4 m_pInstance = new Singleton;//5 UnLock(m_mutex); //6 } return *m_pInstance; //7 } private: static volatitle Singleton *m_pInstatnce; //8 private: Singleton(); //9 Singleton(const Singleton&); //10 Singleton& operator=(const Singleton&); //11 ~Singleton(); //12 } Singleton *Singleton:m_pInstatnce = NULL; //13
3 Singleton銷毀
在這里,我們就到了Singleton最簡單也最復(fù)雜的地方了。
為什么說它簡單?我們根本可以不理睬創(chuàng)建的對(duì)象m_pInstance的銷毀啊。因?yàn)殡m然我們一直沒有將Singleton對(duì)象刪除,但不會(huì)造成內(nèi)存泄漏。為什么這樣說呢?因?yàn)橹挥挟?dāng)你分配了累積行數(shù)據(jù)并丟失了對(duì)他的所有reference是,內(nèi)存泄漏才發(fā)生。而對(duì)Singleton并不屬于上面的情況,沒有累積性的東東,而且直到結(jié)束我們還有它的引用。在現(xiàn)代操作系統(tǒng)中,當(dāng)一個(gè)進(jìn)程結(jié)束后,將自動(dòng)將該進(jìn)程所有內(nèi)存空間完全釋放。(可以參考《effective C++》條款10,里面講述了內(nèi)存泄漏)。
但有時(shí)泄漏還是存在的,那是什么呢?就是資源泄漏。比如說如果該Singleton對(duì)象管理的是網(wǎng)絡(luò)連接,OS互斥量,進(jìn)程通信的handles等等。這時(shí)我們就必須考慮到Singleton的銷毀了。談到銷毀,那可是一個(gè)復(fù)雜的課題(兩天三夜也說不完^_^ 開玩笑的啦,大家輕松一下嘛)。
我們需要在恰當(dāng)?shù)牡攸c(diǎn),恰當(dāng)?shù)臅r(shí)機(jī)刪除Singleton對(duì)象,并且還要在恰當(dāng)?shù)臅r(shí)機(jī)創(chuàng)建或者重新創(chuàng)建Singleton對(duì)象。
在我們的“解二”中,在程序結(jié)束時(shí)會(huì)自動(dòng)調(diào)用Singleton的析構(gòu)函數(shù),那么也將自動(dòng)釋放所獲取的資源。在大多數(shù)情況下,它都能夠有效運(yùn)作。那特殊情況是什么呢?
我們以KDL(keyboard,display,log)模型為例,其中K,D,L均使用Singleton模式。只要keyboard或者display出現(xiàn)異常,我們就必須調(diào)用log將其寫入日志中,否則log對(duì)象不應(yīng)該創(chuàng)建。對(duì)后面一條,我們的Singleton創(chuàng)建時(shí)就可以滿足。
在前面我們已經(jīng)說到,在產(chǎn)生一個(gè)對(duì)象時(shí)(非用new產(chǎn)生的對(duì)象),由編譯器自動(dòng)調(diào)用了atexit(__DestroyObject)函數(shù)來實(shí)現(xiàn)該對(duì)象的析構(gòu)操作。而C++對(duì)象析構(gòu)是LIFO進(jìn)行的,即先產(chǎn)生的對(duì)象后摧毀。
如果在一般情況下調(diào)用了log對(duì)象,然后開始銷毀對(duì)象。按照“后創(chuàng)建的先銷毀”原則:log對(duì)象將被銷毀,然后display對(duì)象開始銷毀。此時(shí)display在銷毀發(fā)現(xiàn)出現(xiàn)異常,于是調(diào)用log對(duì)象進(jìn)行記錄。但事實(shí)上,log對(duì)象已經(jīng)被銷毀,那么調(diào)用log對(duì)象將產(chǎn)生不可預(yù)期的后果,此問題我們稱為Dead Reference。所以前面的解決方案不能解決目前我們遇到的問題。
Andrei Alexandrescu提出了解決方案,稱為Phoenix Singleton(取自鳳凰涅磐典故)
/*解四*/ class Singleton { public: static Singleton &Instance(){ if( !m_pInstatnce){ Lock(m_mutex) If( !m_pInstance ){ if(m_destroyed) OnDeadReference(); else Create(); } UnLock(m_mutex); } return *m_pInstance; } private: static volatitle Singleton *m_pInstatnce; static bool m_destroyed; private: Singleton(); Singleton(const Singleton&); Singleton& operator=(const Singleton&); ~Singleton(){ m_pInstance = 0; m_destroyed = true; } static void Create(){ static Singleton sInstance; m_pInstanace = &sInstance; } static void OnDeadReference(){ Create(); new (m_pInstance) Singleton; atexit(KillPhoenixSingleton); m_destroyed = false; } void KillPhoenixSingleton(){ m_pInstance->~Singleton(); } } Singleton *Singleton:m_pInstatnce = NULL; bool m_destroyed =false;
請(qǐng)注意此處OnDeadReference()中所使用的new操作符的用法:是所謂的placement new操作,它并不分配內(nèi)存,而是在某個(gè)地址上構(gòu)造一個(gè)新對(duì)象。
這是解決Dead Reference方法之一。如果此時(shí)keyboard或者display對(duì)象也需要處理Dead Reference問題時(shí),那么上面的OnDeadReference將被頻繁調(diào)用,效率將會(huì)很低。即該問題為:需要提供一種解決方案,用于處理對(duì)象的建立過程可以不按照“先創(chuàng)建會(huì)銷毀”的原則,而應(yīng)該為其指定一個(gè)銷毀順序。
聰明的Andrei Alexandrescu提出了一個(gè)“帶壽命的Singleton”解決方案。該方案的思想是:利用atexit()的特性;在每次創(chuàng)建一個(gè)對(duì)象后,將該對(duì)象放入到一個(gè)鏈表中(該鏈表是按照銷毀順序排訓(xùn)的),并同時(shí)調(diào)用atexit()注冊一個(gè)銷毀函數(shù);該銷毀函數(shù)從鏈表中獲取最需要銷毀的對(duì)象進(jìn)行銷毀。
到此,關(guān)于“Singleton模式創(chuàng)建、多線程與銷毀的方法是什么”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí),請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站,小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。