轉載自：http://www.cppblog.com/suiaiguo/archive/2009/07/24/91003.html
C++當中常常需要一個全局唯一的對象實例，這時候，我們就會想到單件模式。如何實現這一模式？全局變量當然是一個簡單可行的方法，然而，這太丑陋。嗯，其實，丑陋倒也罷了，最嚴重的是它將引誘程序員濫用全局變量，這將導致維護的災難。
既然全局變量是可能有害的，那么，我們我們把它隱藏一下，放到某個類當中去，作為類的靜態數據成員。這看上去不錯，我也這么認為。當我們只是簡單的需要一個全局對象時，這很好，而且足夠簡單。不過，天空中尚有一朵小小的烏雲，讓我們來看一看它是什么。
靜態成員變量的初始化，和全局對象一樣，實際上是在main函數進入后，我們寫下的第一行代碼之前被執行的。而且，我們知道那個著名的初始化順序不可靠的問題（跨編譯單元）。當我的全局對象是一個復雜對象――這很常見，比如一個環境管理器――它甚至還需要復雜的裝配過程，我們需要考慮：構建這個單件的時候，其對象都准備好了嗎？如果我們不能確定，那么一個常見的措施是延遲單件對象的構造――把它延遲到全局對象初始化結束以后怎么樣？這好像很容易實現：
SomeClass * SomeClass ::instance(){ static SomeClass inst; return &inst; }
不錯吧？它不但可以延遲到全局對象初始化之后，甚至可以延遲到有人需要它的時候，才被構造出來，隨需應變，呵呵，是不是很帥？嗯，還有一點小問題，不僅存在對象初始化順序問題，析構也同樣存在問題。局部靜態變量的析構，和全局對象一樣，是在main函數退出前進行的，如果也要考慮順序問題的話...是不是有點麻煩呢？
過度設計是一種罪，我是不是考慮的太復雜了？如果壓根就不需要考慮析構順序，這是不是很完美的解決方案？沒那么簡單！非但不夠完美，而且，這里面仍然存在缺陷：當我們運行在多線程環境的時候，靜態變量的初始化來實現單件，是不可靠的――直接的說，靜態變量有可能初始化多次！在作實驗之前，我們現分析一下靜態局部變量的實現方式，下面是前面instance實現的偽碼：
if (!initialized){ initialized = true; new (&inst)SomeClass; } return &inst;
每個靜態變量都會擁有自己的初始化與否的標志，靜態變量初始化並不是一個原子操作，也沒有為多線程而設立互斥區（C++語言本身是沒有線程概念的），因此，我們要想實現多線程下的單件延遲創建，就不得不解決重復初始化的問題。至於如何實現，實際上這方面的代碼很多了。一個顯然的方案是設立互斥區，傳統的雙檢測技術可以有效解決這一問題――至少目前的C++是這樣，至於最近在csdn看到在Java中雙檢測失效的文章，我認為應該由Java語言負責。
其實，局部靜態變量可能多次初始化，並不難理解，實踐上，也很少出嚴重的問題――出問題的條件還是挺苛刻的：多線程，不可多次初始化，恰好多個線程同時調用，恰好在if之后發生線程調度。很少出問題，不等於不出問題，特別的，對於廣泛使用的應用程序來說，出錯概率就不是一點點了。寫這篇東西的原因，是今天在公司看到的一段代碼，作了標識符替換：
SomeClass * SomeClass::GetInstance(){ static CLock g_lock; if (m_pInstance == NULL){ g_lock.Lock(); if (m_pInstance == NULL){ m_pInstance = new SomeClass; } g_lock.Unlock(); } return m_pInstance; }
就這段代碼，雖然知道用雙檢測，且不說Lock/Unlock可以更好的處理，static CLock g_lock根本就是錯誤。鎖本身可能被初始化多次，象這種資源類型的對象，多次構造幾乎肯定會出錯的。而對於單件模式的實現，我認為，一般而言，Loki:: SingletonHolder會是一個好的選擇。