單件（Singelton）模式可以說是眾多設計模式當中，理解起來最容易，概念最為簡單的一個。并且在實際的設計當中也是使用得又最為頻繁 的，甚至有很多其它的模式都要借助單件才能更好地實現。然而就是這樣被強烈需求的“一句話模式”（一句話就能闡述明白），雖然有無數的牛人浸淫其中，至今 也沒有誰鼓搗出一個完美的實現。我小菜鳥一只自然更不敢逢人便談單件。不過這個貼的主題是跟單件模式是密不可分的。

　　什么又叫做“線程相關的單件模式”呢？也許你已經顧名思義猜出了八九分。不過還是允許我簡單地用實例說明一下。

　　假設你要設計了一個簡單的 GUI 框架，這個框架當中需要這樣一個全局變量（單件模式），它保存了所有窗口句柄與窗口指針的映射（我見過的數個的開源 GUI 框架都有類似的東西。）。在 WIN32 平臺上就是這樣一個簡單的東西：

    //窗口的包裝類
    class Window
    {
        HWND m_hwnd;
     public:
         bool create();    
         bool destroy();
    
     //其它細節
    };
    
    //窗口句柄與其對象指針的映射
    typedef map<HWND,Window*> WindowMap;
    typedef WindowMap::iterator WindowIter;
    WindowMap theWindowMap;

　　每創建一個窗口，就需要往這個 theWindowMap 當中添加映射。每銷毀一個窗口，則需要從其中刪除掉相關映射。實現代碼類似：

    //創建窗口
    bool Window::create()
    {
        m_hwnd=::CreateWindow(/*參數略*/);
        if(!::IsWindow(m_hwnd))
            return false;
        
        theWindowMap[m_hwnd]=this;       //添加映射
        return true;
    }
        
    //銷毀窗口
    bool Window::destroy()
    {
        ::DestroyWindow(m_hwnd);
        
        theWindowMap.erase(m_hwnd);    //刪除映射
        return true;
    }

　　你可以用任何可能的單件模式來實現這樣一個全局變量 theWindowMap，它會 工作得很好。但是當如果考慮要給程序添加多線程支持（“多線程”是如此麻煩，它總愛和“但是”一起出現，給本來進行得很順利的事情引起波折。），就會發現 此時也許純粹的單件模式并不是最好的選擇。例如一個線程同時創建窗口，那么兩個線程同時調用：

    theWindowMap[m_hwnd]=this;

　　這顯然不是一個原子操作，可以肯定如果你堅持這樣干你的程序會慢慢走向崩潰，幸運一點只是程序運行結果錯誤，如果你恰好那幾天印堂發暗面色發灰，說不定就因為這小小的錯誤，被無良的BOSS作為借口開除掉了，那可是個悲慘的結局。

　　當然大多數的單件模式已經考慮到了多線程的問題。它們的解決方案就是給加上線程鎖 ,我在數個開源的 GUI 框架看到他們都采用了這種解決方案。不過這樣做，在線程同步過程當中，會產生與 GUI 框架邏輯不相關的同步消耗，雖然不是什么大不了的消耗，但是客戶可能因此就選擇了你的竟爭對手，如果線程竟爭激烈，在強烈渴求資源的環境（如小型移動設 置）當中，這種消耗更是不可忽視的。

　　實際上在應用當中，極少有線程需要插入刪除其它線程創建的窗口映射（如果確實有這種需要，那么可以肯定項目的設計上出了問題）。在這種情況下本 線程創建窗口映射都將只是本線程存取，類似“Thread-Specific”的概念。也就是說，theWindowMap 當中其它線程創建的窗口的映射對于本線程來說都是不需關心的，我們卻要為那部分不必要東西整天提心吊膽并付出運行時消耗的代價，這也有點像“穿著棉襖洗 澡”。但是怎么樣才能做到更輕松爽快些呢？

　　就本例問題而言，我們需要這樣一種變量來保存窗口映射，它針對每個線程有不同的值（Thread-Specific Data），這些值互不影響，并且所有線程對它的訪問如同是在訪問一個進程內的全局變量（Singelton）。

　　如果你是熟悉多線程編程的人，那么“Thread-Specific ”一定讓你想起了什么。是的，“Thread-Specific Storage ” （線程相關存存諸，簡稱 TSS ），正是我們需要的，這是大多數操作系統都提供了的一種線程公共資源安全機制，這種機制允許以一定方式創建一個變量，這個變量在所在進程當中的每個線程當 中，可以擁有不同的值。在 WIN32 上，這個變量就稱為“索引”，其相關的值則稱為“槽”， “Thread-Local Storage”（線程局部存諸，簡稱 TLS ）機制。它的提了供這樣幾個函數來定義，設置，讀取線程相關數據（關于 TLS 的更多信息，可以查閱 MSDN ）：

    //申請一個“槽”的索引。
    DWORD TlsAlloc( void );
    
    //獲得調用線程當中指定“槽”的值。
    VOID* TlsGetValue( DWORD dwTlsIndex );
    
    //設置調用線程當中指定“槽”的值。
    BOOL  TlsSetValue( DWORD dwTlsIndex,VOID* lpTlsValue );
    
    //釋放掉申請的“槽”的索引
    BOOL  TlsFree( DWORD dwTlsIndex );

　　具體使用流程方法：先調用 TlsAlloc 申請一個“索引”，然后線程在適當時機創建一個對象并調用 TlsSetValue 將“索引”對應的“槽”設置為該對象的指針，在此之后即可用 TlsGetValue 訪問該“糟”。最后在不需要的時候調用 TlsFree ，如在本例當中，調用 TlsFree 的最佳時機是在進程結束時。

　　先封裝一下 TlsAlloc 和 TlsFree  以方便對 ”索引“的管理。

    class TlsIndex
    {
    public:
        TlsIndex()
            :m_index(::TlsAlloc())
        {}
    
        ~TlsIndex()
        {
            ::TlsFree(m_index);
        }
    
    public:
        operator DWORD() const
        {
            return m_index;
        }
    
    private:
        DWORD m_index;
    };

　　
　　如你所見，類 TlsIndex 將在構造的時候申請一個“索引”，在析構的時候釋放此“索引”。

　　在本例當中 TlsIndex 的對象應該存在進程的生命周內，以保證在進程退出之前，這個“索引”都不會被釋放，這樣的 TlsIndex 對象聽起來正像一個全局靜態對象，不過 Meyers Singelton （用函數內的靜態對象實現）在這里會更適合，因為我們不需要對這個對象的生命周末進行精確控制，只需要它在需要的時候創建，然后在進程結束前銷毀即可。這 種方式只需要很少的代碼即可實現，比如：

    DWORD windowMapTlsIndex()
    {
        static TlsIndex s_ti;　　//提供自動管理生命周期的“索引”
        return s_ti;
    }

　　利用這個“索引”，我們就能實現上述“Thread-Specific”的功能：

    WindowMap* windowMap()
    {
        WindowMap* wp=reinterpret_cast<WindowMap*>(::TlsGetValue(windowMapTlsIndex()));
        if(!wp)
        {
            wp=new WindowMap();
            ::TlsSetValue(windowMapTlsIndex(),wp);
        }
        return wp;
    }
    
    #define theWindowMap *(windowMap())

　　
　　注意各線程訪問以上的代碼不會存在竟爭。這樣就實現了一個線程安全且無線程同步消耗版本的“全局對象” theWindowMap 。我們甚至不用改變Window::create，Window::destory，queryWindow 的代碼，

　　這幾個簡單的函數看起來似乎不像一個“模式”，但是它確實是的。

　　現在總結一下“線程相關的單件模式”的概念：保證一個類在一個線程當中只有一個實例，并提供一個訪問它的線程內的訪問點的模式。

　　為了不重復地制造車輪，我將此類應用的模式封裝了一下：

    template<typename TDerived>
    class TlsSingelton
    {
        typedef TDerived    _Derived;
        typedef TlsSingelton<TDerived> _Base;
    
    public:
        static _Derived* tlsInstance()
        {
            return tlsCreate();    
        }
    
    protected:
        static _Derived* tlsCreate()
        {
            _Derived* derived=tlsGet();
            if(derived)
                return derived;
    
            derived=new _Derived();
            if(derived && TRUE==::TlsSetValue(tlsIndex(),derived))
                return derived;
    
            if(derived)
                delete derived;
    
            return NULL;
        }
    
        static bool tlsDestroy()
        {
            _Derived* derived=tlsGet();
            if(!derived)
                return false;
    
            delete derived;
            return true;
        }
    
        static DWORD tlsIndex()
        {
            static TlsIndex s_tlsIndex;
            return s_tlsIndex;
        }
    
    private:
        static _Derived* tlsGet()
        {
            return reinterpret_cast<_Derived*>(::TlsGetValue(tlsIndex()));
        }
    
        static bool tlsSet(_Derived* derived)
        {
            return TRUE==::TlsSetValue(tlsIndex(),derived);
        }
    
    //noncopyable
    private:
        TlsSingelton(const _Base&);
        TlsSingelton& operator=(const _Base&);
    };
    

　　將 tlsCreate，tlsDestroy 兩個函數設置為保護成員，是為了防止一些不三不四吊爾啷噹的程序隨意地刪除。

　　示例：

    class WindowMapImpl:public TlsSingelton<WindowMap>
    {
        WindowMap m_map;
    public:
        WidnowMap& theWindowMapImpl()
        {
            return m_map;
        }
    
    public:
        ~WindowMapImpl();
        
    protected:
        WindowMapImpl(); //只能通過tlsCreate創建
        friend class _Base;
    };
        
    #define theWindowMap (WindowMapImpl::tlsInstance()->theWindowMapImpl())

　　仍不需要修改原有窗口代碼。