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

總結

以上是生活随笔為你收集整理的多线程中局部静态变量初始化的陷阱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。