都是從網上學得,整理下本身的理解。 c++
單例模式有兩種實現模式:安全
1)懶漢模式: 就是說當你第一次使用時才建立一個惟一的實例對象,從而實現延遲加載的效果。網絡
2)餓漢模式: 就是說無論你未來用不用,程序啓動時就建立一個惟一的實例對象。多線程
因此,從實現手法上看, 懶漢模式是在第一次使用單例對象時才完成初始化工做。由於此時可能存在多線程競態環境,如不加鎖限制會致使重複構造或構造不徹底問題。併發
餓漢模式則是利用外部變量,在進入程序入口函數以前就完成單例對象的初始化工做,此時是單線程因此不會存在多線程的競態環境,故而無需加鎖。 函數
如下是典型的幾種實現高併發
class Singleton { public: static Singleton* GetInstance() { if (m_pInstance == NULL ) { Lock(); // 加鎖 if (m_pInstance == NULL ) { m_pInstance = new Singleton (); } UnLock(); // 解鎖 } return m_pInstance; } // 實現一個內嵌垃圾回收類 class CGarbo { public: ~CGarbo() { if(Singleton::m_pInstance) delete Singleton::m_pInstance; } }; static CGarbo Garbo; // 定義一個靜態成員變量,程序結束時,系統會自動調用它的析構函數從而釋放單例對象 private: Singleton(){}; Singleton(Singleton const&); Singleton& operator=(Singleton const&); static Singleton* m_pInstance; }; Singleton* Singleton::m_pInstance = NULL; Singleton::CGarbo Garbo;
這裏仍然要注意的是局部變量初始化的線程安全性問題,在C++0X之後,要求編譯器保證靜態變量初始化的線程安全性,能夠不加鎖。但C++ 0X之前,仍須要加鎖。性能
class Singleton { public: static Singleton* GetInstance() { Lock(); // not needed after C++0x static Singleton instance; UnLock(); // not needed after C++0x return &instance; } private: Singleton() {}; Singleton(const Singleton &); Singleton & operator = (const Singleton &); };
在懶漢模式裏,若是大量併發線程獲取單例對象,在進行頻繁加鎖解鎖操做時,必然致使效率低下。spa
由於程序一開始就完成了單例對象的初始化,因此後續再也不須要考慮多線程安全性問題,就能夠避免懶漢模式裏頻繁加鎖解鎖帶來的開銷。插件
class Singleton { public: static Singleton* GetInstance() { return &m_instance; } private: Singleton(){}; Singleton(Singleton const&); Singleton& operator=(Singleton const&); static Singleton m_instance; }; Singleton Singleton::m_instance; // 在程序入口以前就完成單例對象的初始化
雖然這種實如今必定程度下能良好工做,可是在某些狀況下會帶來問題 --- 就是在C++中 」非局部靜態對象「 的 」初始化「 順序 的 」不肯定性「, 參見Effective c++ 條款47。
考慮: 若是有兩個這樣的單例類,將分別生成單例對象A, 單例對象B. 它們分別定義在不一樣的編譯單元(cpp中), 而A的初始化依賴於B 【 即A的構造函數中要調用B::GetInstance() ,而此時B::m_instance 可能還未初始化,顯然調用結果就是非法的 】, 因此說只有B在A以前完成初始化程序才能正確運行,而這種跨編譯單元的初始化順序編譯器是沒法保證的。
在前面的方案中:餓漢模式中,使用到了類靜態成員變量,可是遇到了初始化順序的問題; 懶漢模式中,使用到了靜態局部變量,可是存在着線程安全等問題。
boost 的實現方式是:單例對象做爲靜態局部變量,而後增長一個輔助類,並聲明一個該輔助類的類靜態成員變量,在該輔助類的構造函數中,初始化單例對象。如下爲代碼
class Singleton { public: static Singleton* GetInstance() { static Singleton instance; return &instance; } protected: // 輔助代理類 struct Object_Creator { Object_Creator() { Singleton::GetInstance(); } }; static Object_Creator _object_creator; Singleton() {} ~Singleton() {} }; Singleton::Object_Creator Singleton::_object_creator;
首先,代理類這個外部變量初始化時,在其構造函數內部調用 Singleton::GetInstance();從而間接完成單例對象的初始化,這就經過該代理類實現了餓漢模式的特性。
其次,仍然考慮第三種模式的缺陷。 當A的初始化依賴於B, 【 即A的構造函數中要調用B::GetInstance() ,而此時B::m_instance 可能還未初始化,顯然調用結果就是非法的 】 如今就變爲【在A的構造函數中要調用B::GetInstance() ,若是B還沒有初始化,就會引起B的初始化】,因此在不一樣編譯單元內全局變量的初始化順序不定的問題就隨之解決。
最後,關於使用懶漢仍是餓漢模式,個人理解:
若是這個單例對象構造十分耗時或者佔用不少資源,好比加載插件啊, 初始化網絡鏈接啊,讀取文件啊等等,而有可能該對象程序運行時不會用到,那麼也要在程序一開始就進行初始化,也是一種資源浪費吧。 因此這種狀況懶漢模式(延遲加載)更好。
若是這個單例對象在多線程高併發環境下頻繁使用,性能要求較高,那麼顯然使用餓漢模式來避免資源競爭,提升響應速度更好。