說來慚愧，自己在畢業之前就該好好看看《劍指Offer》這本書的，但是各種原因就是沒看，也因此錯過了很多機會，後悔莫及。但是後悔是沒用的，現在趁還有餘力，把這本書好好看一遍，並通過C#通通實現一遍，並記錄在我的部落格中，作為學習筆記。

一、題目：實現Singleton模式

題目：設計一個類，我們只能生成該類的一個例項。　

　　只能生成一個例項的類是實現了Singleton（單例）模式的型別。由於設計模式在面向物件程式設計中起著舉足輕重的作用，在面試過程中很多公司都喜歡問一些與設計模式相關的問題。在常用的模式中，Singleton是唯一一個能夠用短短几十行程式碼完整實現的模式。因此，寫一個Singleton的型別是一個很常見的面試題。

　　例如，在一個Flappy Bird遊戲中，小鳥這個遊戲物件在整個遊戲中應該只存在一個例項，所有對於這個小鳥的操作（向上飛、向下掉等）都應該只會針對唯一的一個例項進行。

二、幾種不好的解法

2.1 不好的解法一：只適用於單執行緒環境

    public sealed class Singleton1
    {
        private Singleton1() { }

        private static Singleton1 instance = null;

        public static Singleton1 Instance
        {
            
 
get
            {
                if(instance == null)
                {
                    instance = new Singleton1();
                }

                return instance;
            }
        }
    }

　　解法一的程式碼在單執行緒的時候工作正常，但在多執行緒的情況下多個執行緒都會建立一個自己的例項，無法保證單例模式的要求。

2.2 不好的解法二：雖然在多執行緒環境中能工作但效率不高　

    public sealed class Singleton2
    {
        private Singleton2() { }

        private static readonly object syncObject = new object();

        private static Singleton2 instance = null;

        public static Singleton2 Instance
        {
            get
            {
                // 每個執行緒來之前先等待鎖
                lock(syncObject)
                {
                    if (instance == null)
                    {
                        instance = new Singleton2();
                    }
                }

                return instance;
            }
        }
    }

　　解法二就保證了我們在多執行緒環境中也只能得到一個例項，但是加鎖是一個非常耗時的操作，在沒有必要的時候我們應該儘量避免。

2.3 可行的解法三：加同步鎖前後兩次判斷例項是否已存在

　　前面講到的執行緒安全的實現方式的問題是要進行同步操作，那麼我們是否可以降低通過操作的次數呢？其實我們只需在同步操作之前，新增判斷該例項是否為null就可以降低通過操作的次數了，這樣是經典的Double-Checked Locking方法，修改上面的屬性程式碼如下：

    public static Singleton3 Instance
    {
        get
        {
            // Double-Check 雙重判斷避免不必要的加鎖
            if (instance == null)
            {
                // 確定例項為空時再等待加鎖
                lock (syncObject)
                {
                    // 確定加鎖後例項仍然未建立
                    if (instance == null)
                    {
                        instance = new Singleton3();
                    }
                }
            }

            return instance;
        }
    }

　　解法三用加鎖機制來確保在多執行緒環境下只建立一個例項，並且用兩個if判斷來提高效率。但是，這樣的程式碼實現起來比較複雜，容易出錯。

三、兩種較好的解法

3.1 較好的解法一：利用靜態建構函式

C#的語法中有一個函式能夠確保只調用一次，那就是靜態建構函式。由於C#是在呼叫靜態建構函式時初始化靜態變數，.NET執行時（CLR）能夠確保只調用一次靜態建構函式，這樣我們就能夠保證只初始化一次instance。

    public sealed class Singleton4
    {
        private Singleton4() { }
        // 在大多數情況下，靜態初始化是在.NET中實現Singleton的首選方法。
        static Singleton4() { }

        private static readonly Singleton4 instance = new Singleton4();

        public static Singleton4 Instance
        {
            get
            {
                return instance;
            }
        }
    }

　　該解法是在 .NET 中實現 Singleton 的首選方法，但是，由於在C#中呼叫靜態建構函式的時機不是由程式設計師掌控的，而是當.NET執行時發現第一次使用該型別的時候自動呼叫該型別的靜態建構函式（也就是說在用到Singleton4時就會被建立，而不是用到Singleton4.Instance時），這樣會過早地建立例項，從而降低記憶體的使用效率。此外，靜態建構函式由 .NET Framework 負責執行初始化，我們對對例項化機制的控制權也相對較少。

3.2 較好的解法二：實現按需建立例項

    public sealed class Singleton5
    {
        private Singleton5() { }

        public static Singleton5 Instance
        {
            get
            {
                return Nested.instance;
            }
        }

        // 使用內部類+靜態建構函式實現延遲初始化
        class Nested
        {
            static Nested() { }

            internal static readonly Singleton5 instance = new Singleton5();
        }
    }

　　該解法在內部定義了一個私有型別Nested。當第一次用到這個巢狀型別的時候，會呼叫靜態建構函式建立Singleton5的例項instance。如果我們不呼叫屬性Singleton5.Instance，那麼就不會觸發.NET執行時（CLR）呼叫Nested，也就不會建立例項，因此也就保證了按需建立例項（或延遲初始化）。

四、總結

　　在前面的5種實現單例模式的方法中：

　　第一種方法在多執行緒環境中不能正常工作，第二種模式雖然能在多執行緒環境中正常工作但時間效率很低，都不是面試官期待的解法。在第三種方法中我們通過兩次判斷一次加鎖確保在多執行緒環境能高效率地工作。

　　第四種方法利用C#的靜態建構函式的特性，確保只建立一個例項。第五種方法利用私有巢狀型別的特性，做到只在真正需要的時候才會建立例項，提高空間使用效率。

作者：周旭龍

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。