<strike id="5ntnv"><i id="5ntnv"><del id="5ntnv"></del></i></strike>
<strike id="5ntnv"></strike><ruby id="5ntnv"></ruby><del id="5ntnv"><dl id="5ntnv"><del id="5ntnv"></del></dl></del><strike id="5ntnv"><dl id="5ntnv"><del id="5ntnv"></del></dl></strike>
<strike id="5ntnv"></strike>
<strike id="5ntnv"></strike>
<span id="5ntnv"><dl id="5ntnv"></dl></span>
<strike id="5ntnv"><i id="5ntnv"><del id="5ntnv"></del></i></strike><th id="5ntnv"><noframes id="5ntnv"><span id="5ntnv"><dl id="5ntnv"><del id="5ntnv"></del></dl></span>
<span id="5ntnv"></span>
<strike id="5ntnv"><dl id="5ntnv"><del id="5ntnv"></del></dl></strike>
<strike id="5ntnv"><dl id="5ntnv"><del id="5ntnv"></del></dl></strike><strike id="5ntnv"><i id="5ntnv"></i></strike><span id="5ntnv"></span>
<strike id="5ntnv"></strike>
<strike id="5ntnv"></strike>
<th id="5ntnv"><noframes id="5ntnv">
<ruby id="5ntnv"></ruby>
<strike id="5ntnv"><dl id="5ntnv"></dl></strike>

貴州網站建設公司貴州網站建設公司

設計模式:Singleton模式

以下內容摘自http://www.uml.org.cn/sjms/sjms112401.htm,設計式呵呵... 以后做參考。模式n模

GOF著作中對Singleton模式的設計式描述為:保證一個class只有一個實體(Instance),并為它提供一個全局訪問點(global access point)。

從其描述來看,模式n模是設計式非常簡單的,但實現該模式卻是模式n模復雜的。Singleton設計模式不存在一種所謂的設計式“最佳”方案。需要根據當時的模式n模具體問題進行具體解決,下面將講述在不同環境下的設計式解決方案。

Singleton的模式n模詳細解釋,請大家看GOF的設計式著作《設計模式》一書。俺比較懶,模式n模是設計式不想抄了。J

1         Singleton創建

1.1      GOF Singleton

在GOF著作中對Singleton模式的模式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

 

在上面的解決方案中,我們只在需要調用時,設計式才產生一個Singleton的對象。這樣帶來的好處是,如果該對象產生帶來的結果很昂貴,但不經常用到時,是一種非常好的策略。但如果該Instance被頻繁調用,那么就有人覺得Instance中的判斷降低了效率(雖然只是一個判斷語句^_^),那么我們就把第5條語句該為

static Singleton m_Instatnce;

如此一來,在Instatnce直接返回&m_Instance,而不用做任何判斷,效率也高了。(是不是呢?)

這樣修改后,我們將帶來災難性的后果:

1:首先有可能編譯器這關就沒法通過,說m_Instance該外部變量無法解決(visural C++6.0)

error LNK2001: unresolved external symbol "private: static class Singleton  Singleton::m_Instance" (?m_Instance@Singleton@@0V1@A)

2:如果編譯器這關通過了就沒問題了么?答案是否定的。

第一是不管Instance是否用到,該靜態變量對象在編譯器編譯時就產生了,即資源消耗是不可避免的;

第二是無法確保編譯器一定先將m_Instance初始化。所以Instance的調用有可能傳回一個尚沒構造的Singleton對象。這也意味著你無法保證任何外部對象所使用的m_Instance是一個被正確初始化的對象。

1.2      Meyers Singleton

我們如何解決這個問題呢,實際上很簡單。一種非常優雅的做法由Scott Meyers最先提出,故也稱為Meyers Singleton。它依賴編譯器的神奇技巧。即函數內的static對象只在該函數第一次執行時才初始化(請注意不是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中定義了一個Static的Singleton對象,來解決Instance中初始化的問題,也很順利的解決了定義Static成員對象帶來的問題。

請注意,解二在VC6中不能編譯通過,將有以下的錯誤:

error C2248: 'Singleton::~Singleton' : cannot access private member declared in class 'Singleton' e:\work\q\a.h(81) : see declaration of 'Singleton::~Singleton'

產生該問題的錯誤原因是什么呢(請仔細思考^_^)

原因在于在產生static Singleton對象后,編譯器會自動產生一個銷毀函數__DestroySingleton,然后調用atexit()注冊,在程序退出時執行__DestroySingleton。但由于Singleton的析構函數是private,所以會產生訪問錯誤。(應該在以后的編譯器中修改了該BUG)

1.3      Singleton改進

讓Instance傳回引用(reference)。如果傳回指針,調用端有可能講它delete調。

1.4      Singleton注意之點

在上面的解法中,請注意對構造函數和析構函數的處理,有何好處(請自己理解,俺懶病又犯了L)。

2         多線程

在解一中,如果我們運行在多線程的環境中,該方案是完美的么,將會有什么后果呢?

后果就是會造成內存泄漏,并且有可能前后獲取的Singleton對象不一樣(原因請自己思考,后面有解答)。

為了解決這個問題,將解一的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

}

此種方法將解決解一運行在多線程環境下內存泄漏的問題,但帶來的結果是,當m_mutex被鎖定時,其它試圖鎖定m_mutex的線程都將必須等等。并且每次執行鎖操作其付出的代價極大,亦即是這種方案的解決辦法并不吸引人。

那么我們將上面的代碼改為如下方式:

Singleton& Singleton::Instance(){

If( !m_pInstance ){                                                       //1

Lock(m_mutex); //含義為獲取互斥量 //2

m_pInstance = new Singleton; //3

UnLock(m_mutex); //4

}

return *m_pInstance;                                                 //5

}

這樣修改的結果沒有問題了么?NO!!!!該方案帶來的結果同解一,原因也一樣,都將造成內存泄漏。此時“雙檢測鎖定”模式就粉墨登場了。

由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

}

請看上面的第三句,這句話是不是具有化腐朽為神奇的力量啊 ^_^

上面的方案就完美了么。回答還是NO!!!(各位看官是否已經郁悶了啊,這不是玩我啊?請耐心點,聽我細細到來^_^)

如果在RISC機器上編譯器有可能將上面的代碼優化,在鎖定m_mutex前執行第3句。這是完全有可能的,因為第一句和第3句一樣,根據代碼優化原則是可以這樣處理的。這樣一來,我們引以為自豪的“雙檢測鎖定”居然沒有起作用( L)

怎么辦?解決唄。怎么解決?簡單,我們在m_pInstance前面加一個修飾符就可以了。什么修飾符呢?…….

 

àvolatile(簡單吧,讓我們J吧)

那么我們完整的解法如下:

/*解三*/

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最簡單也最復雜的地方了。

為什么說它簡單?我們根本可以不理睬創建的對象m_pInstance的銷毀啊。因為雖然我們一直沒有將Singleton對象刪除,但不會造成內存泄漏。為什么這樣說呢?因為只有當你分配了累積行數據并丟失了對他的所有reference是,內存泄漏才發生。而對Singleton并不屬于上面的情況,沒有累積性的東東,而且直到結束我們還有它的引用。在現代操作系統中,當一個進程結束后,將自動將該進程所有內存空間完全釋放。(可以參考《effective C++》條款10,里面講述了內存泄漏)。

但有時泄漏還是存在的,那是什么呢?就是資源泄漏。比如說如果該Singleton對象管理的是網絡連接,OS互斥量,進程通信的handles等等。這時我們就必須考慮到Singleton的銷毀了。談到銷毀,那可是一個復雜的課題(兩天三夜也說不完^_^  開玩笑的啦,大家輕松一下嘛)。

我們需要在恰當的地點,恰當的時機刪除Singleton對象,并且還要在恰當的時機創建或者重新創建Singleton對象。

在我們的“解二”中,在程序結束時會自動調用Singleton的析構函數,那么也將自動釋放所獲取的資源。在大多數情況下,它都能夠有效運作。那特殊情況是什么呢?

我們以KDL(keyboard,display,log)模型為例,其中K,D,L均使用Singleton模式。只要keyboard或者display出現異常,我們就必須調用log將其寫入日志中,否則log對象不應該創建。對后面一條,我們的Singleton創建時就可以滿足。

在前面我們已經說到,在產生一個對象時(非用new產生的對象),由編譯器自動調用了atexit(__DestroyObject)函數來實現該對象的析構操作。而C++對象析構是LIFO進行的,即先產生的對象后摧毀。

如果在一般情況下調用了log對象,然后開始銷毀對象。按照“后創建的先銷毀”原則:log對象將被銷毀,然后display對象開始銷毀。此時display在銷毀發現出現異常,于是調用log對象進行記錄。但事實上,log對象已經被銷毀,那么調用log對象將產生不可預期的后果,此問題我們稱為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; 

請注意此處OnDeadReference()中所使用的new操作符的用法:是所謂的placement new操作,它并不分配內存,而是在某個地址上構造一個新對象。

這是解決Dead Reference方法之一。如果此時keyboard或者display對象也需要處理Dead Reference問題時,那么上面的OnDeadReference將被頻繁調用,效率將會很低。即該問題為:需要提供一種解決方案,用于處理對象的建立過程可以不按照“先創建會銷毀”的原則,而應該為其指定一個銷毀順序。

聰明的Andrei Alexandrescu提出了一個“帶壽命的Singleton”解決方案。該方案的思想是:利用atexit()的特性;在每次創建一個對象后,將該對象放入到一個鏈表中(該鏈表是按照銷毀順序排訓的),并同時調用atexit()注冊一個銷毀函數;該銷毀函數從鏈表中獲取最需要銷毀的對象進行銷毀。(懶病又犯了L。該模式的實現請各位看官自行實現,可以參考《C++設計新思維》一書,Andrei Alexandrescu著)。

 

各位看官,看完本篇后,是否覺得Singleton還簡單啦J

作者:david++
來源鏈接:https://www.cnblogs.com/mywolrd/archive/2009/01/04/1930713.html

贊(17)
未經允許不得轉載:>貴州網站建設公司 » 設計模式:Singleton模式
国产欧美精品