線程安全的單例模式
一、懶漢模式：即第一次調用該類實例的時候才產生一個新的該類實例，并在以后僅返回此實例。
需要用鎖，來保證其線程安全性：原因：多個線程可能進入判斷是否已經存在實例的if語句，從而non thread safety。
使用double-check來保證thread safety。但是如果處理大量數據時，該鎖才成為嚴重的性能瓶頸。
1、靜態成員實例的懶漢模式：
class Singleton{private: static Singleton* m_instance; Singleton(){}public: static Singleton* getInstance();}; Singleton* Singleton::getInstance(){ if(NULL == m_instance) { Lock();//借用其它類來實現，如boost if(NULL == m_instance) { m_instance = new Singleton; } UnLock(); } return m_instance;} 2、內部靜態實例的懶漢模式
這里需要注意的是，C++0X以后，要求編譯器保證內部靜態變量的線程安全性，可以不加鎖。但C++ 0X以前，仍需要加鎖。
class SingletonInside{private: SingletonInside(){}public: static SingletonInside* getInstance() { Lock(); // not needed after C++0x static SingletonInside instance; UnLock(); // not needed after C++0x return instance; }}; 二、餓漢模式：即無論是否調用該類的實例，在程序開始時就會產生一個該類的實例，并在以后僅返回此實例。
由靜態初始化實例保證其線程安全性，WHY？因為靜態實例初始化在程序開始時進入主函數之前就由主線程以單線程方式完成了初始化，不必擔心多線程問題。
故在性能需求較高時，應使用這種模式，避免頻繁的鎖爭奪。
class SingletonStatic{private: static const SingletonStatic* m_instance; SingletonStatic(){}public: static const SingletonStatic* getInstance() { return m_instance; }}; //外部初始化 before invoke mainconst SingletonStatic* SingletonStatic::m_instance = new SingletonStatic;
boost庫的實現示例
單例本來是個很簡單的模式，實現上應該也是很簡單，但C++單例的簡單實現會有一些坑，有了上面線程安全的基礎，下面來看看為了避免這些坑怎樣一步步演化到boost庫的實現方式。
方案一
class QMManager{public: static QMManager &instance() { static QMManager instance_; return instance_; }} 這是最簡單的版本，在單線程下(或者是C++0X下)是沒任何問題的，但在多線程下就不行了，因為static QMManager instance_;這句話不是線程安全的。
在局部作用域下的靜態變量在編譯時，編譯器會創建一個附加變量標識靜態變量是否被初始化，會被編譯器變成像下面這樣（偽代碼）：
static QMManager &instance(){ static bool constructed = false; static uninitialized QMManager instance_; if (!constructed) { constructed = true; new(&s) QMManager; //construct it } return instance_;} 這里有競爭條件，兩個線程同時調用instance()時，一個線程運行到if語句進入后還沒設constructed值，此時切換到另一線程，constructed值還是false，同樣進入到if語句里初始化變量，兩個線程都執行了這個單例類的初始化，就不再是單例了。
方案二
一個解決方法是加鎖：
static QMManager &instance(){ Lock(); //鎖自己實現 static QMManager instance_; UnLock(); return instance_;} 但這樣每次調用instance()都要加鎖解鎖，代價略大。
方案三
那再改變一下，把內部靜態實例變成類的靜態成員，在外部初始化，也就是在include了文件，main函數執行前就初始化這個實例，就不會有線程重入問題了：
class QMManager{protected: static QMManager instance_; QMManager(); ~QMManager(){};public: static QMManager *instance() { return &instance_; } void do_something();};QMManager QMManager::instance_; //外部初始化 這被稱為餓漢模式，程序一加載就初始化，不管有沒有調用到。
看似沒問題，但還是有坑，在一個2B情況下會有問題：在這個單例類的構造函數里調用另一個單例類的方法可能會有問題。
看例子：
//.hclass QMManager{protected: static QMManager instance_; QMManager(); ~QMManager(){};public: static QMManager *instance() { return &instance_; }}; class QMSqlite{protected: static QMSqlite instance_; QMSqlite(); ~QMSqlite(){};public: static QMSqlite *instance() { return &instance_; } void do_something();}; QMManager QMManager::instance_;QMSqlite QMSqlite::instance_;//.cppQMManager::QMManager(){ printf("QMManager constructor/n"); QMSqlite::instance()->do_something();} QMSqlite::QMSqlite(){ printf("QMSqlite constructor/n");}void QMSqlite::do_something(){ printf("QMSqlite do_something/n");} 這里QMManager的構造函數調用了QMSqlite的instance函數，但此時QMSqlite::instance_可能還沒有初始化。
這里的執行流程：程序開始后，在執行main前，執行到QMManager QMManager::instance_;這句代碼，初始化QMManager里的instance_靜態變量，調用到QMManager的構造函數，在構造函數里調用QMSqlite::instance()，取QMSqlite里的instance_靜態變量，但此時QMSqlite::instance_還沒初始化，問題就出現了。
那這里會crash嗎，測試結果是不會，這應該跟編譯器有關，靜態數據區空間應該是先被分配了，在調用QMManager構造函數前，QMSqlite成員函數在內存里已經存在了，只是還未調到它的構造函數，所以輸出是這樣：
QMManager constructorQMSqlite do_somethingQMSqlite constructor
方案四
那這個問題怎么解決呢，單例對象作為靜態局部變量有線程安全問題，作為類靜態全局變量在一開始初始化，有以上2B問題，那結合下上述兩種方式，可以解決這兩個問題。boost的實現方式是：單例對象作為靜態局部變量，但增加一個輔助類讓單例對象可以在一開始就初始化。如下：
//.hclass QMManager{protected: struct object_creator { object_creator() { QMManager::instance(); } inline void do_nothing() const {} }; static object_creator create_object_; QMManager(); ~QMManager(){};public: static QMManager *instance() { static QMManager instance; return &instance; }};QMManager::object_creator QMManager::create_object_; class QMSqlite{protected: QMSqlite(); ~QMSqlite(){}; struct object_creator { object_creator() { QMSqlite::instance(); } inline void do_nothing() const {} }; static object_creator create_object_;public: static QMSqlite *instance() { static QMSqlite instance; return &instance; } void do_something();}; QMManager::object_creator QMManager::create_object_;QMSqlite::object_creator QMSqlite::create_object_; 結合方案3的.cpp，這下可以看到正確的輸出和調用了：
QMManager constructorQMSqlite constructorQMSqlite do_something
來看看這里的執行流程：
初始化QMManager類全局靜態變量create_object_
->調用object_creator的構造函數
->調用QMManager::instance()方法初始化單例
->執行QMManager的構造函數
->調用QMSqlite::instance()
->初始化局部靜態變量QMSqlite instance
->執行QMSqlite的構造函數，然后返回這個單例。
跟方案三的區別在于QMManager調用QMSqlite單例時，方案3是取到全局靜態變量，此時這個變量未初始化，而方案四的單例是靜態局部變量，此時調用會初始化。
跟最初方案一的區別是在main函數前就初始化了單例，不會有線程安全問題。
最終boost
上面為了說明清楚點去除了模版，實際使用是用模版，不用寫那么多重復代碼，這是boost庫的模板實現：
template <typename T>struct Singleton{ struct object_creator { object_creator(){ Singleton<T>::instance(); } inline void do_nothing()const {} }; static object_creator create_object; public: typedef T object_type; static object_type& instance() { static object_type obj; //據說這個do_nothing是確保create_object構造函數被調用 //這跟模板的編譯有關 create_object.do_nothing(); return obj; } };template <typename T> typename Singleton<T>::object_creator Singleton<T>::create_object; class QMManager{protected: QMManager(); ~QMManager(){}; friend class Singleton<QMManager>;public: void do_something(){};}; int main(){ Singleton<QMManager>::instance()->do_something(); return 0;} 其實Boost庫這樣的實現像打了幾個補丁，用了一些奇技淫巧，雖然確實繞過了坑實現了需求，但感覺挺不好的。
