設計模式(2) 單例模式

• 單例模式
• 線程安全的Singleton
• 會破壞Singleton的情況
• 線程級Singleton

單例模式是幾個創建型模式中最獨立的一個，它的主要目標不是根據客戶程序調用生成一個新的實例，而是控制某個類型的實例數量只有一個。
GOF對單例的描述爲：
Ensure a class only has one instance, and provide aglobal point of access to.
—Design Patterns : Elements of Reusable Object-Oriented Software

單例模式

單例模式的應用場景不必贅述，先來一個最簡單的實現方式：

public class Singleton
{
    private Singleton() { }
    private static Singleton instance;
    public static Singleton Instance()
    {
        if (instance == null)
        {
            instance = new Singleton();
        }
        return instance;
    }
}

這裏採用的是Lazy方式，也可以在靜態變量被創建的時候直接初始化實例。
這段代碼已經可以滿足最初Singleton模式的設計要求，在大多數情況下可以很好地工作。但在多線程環境下這種實現方式是存在缺陷的，當多個線程幾乎同時調用Singleton類的Instance靜態屬性的時候，instance成員可能還沒有被實例化，因此它被創建了多次，而且最終Singleton類中保存的是最後創建的那個實例，各個線程引用的對象不同。

線程安全的Singleton

爲了保證多線程環境下instance實例只有一個，對代碼進行了優化：

public class Singleton
{
    private static volatile Singleton instance;
    public static Singleton Instance()
    {
        if (instance == null)
        {
            lock (typeof(Singleton))
            {
                if (instance == null)
                {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

相比最初的實現，改變的地方有這幾處：

• instance使用volatile關鍵字修飾，它表示字段可能被多個併發執行的線程修改。
• 在實例化前lock Singleton類型，避免了多個線程同時實例化的問題。
• 第一個if加在了lock之前，是爲了避免每次調用都鎖定Singleton類型帶來的效率下降。
• lock後再次判斷instance是否爲空，是因爲在高併發場景下，在第一個線程鎖定並實例化期間，仍然可能會有別的線程進入到第一層if內，這樣如果不再次判空，就會重複實例化。

會破壞Singleton的情況

有些情況會破壞Singleton的封裝，跳過“只能有一個實例”的限制，在實際應用中要注意規避。

• 第一種情況就是實現ICloneable接口或繼承自其相關的子類，這樣客戶程序藉助ICloneable接口就可以跳過已經被隱藏起來的構造函數

• 另外通過二進制、Json之類序列化、反序列化的方式也可以產生新的對象。

線程級Singleton

前面討論的是線程安全的Singleton實現，但有時需要的是更細粒度的Singleton，比如線程級的Singleton，只要保證在一個線程內只有一個實例即可，這就類似Asp.NET Core 自帶的IOC提供的AddScope註冊方式，可以保證一個HttpContext內只有一個實例。

雖然Asp.NET Core提供類似的現成實現，但如果在非Web環境下也需要線程級的實例控制該怎麼辦呢？ 結合C#提供的System.ThreadStaticAttribute可以完成

通過System.ThreadStaticAttribute可以將某個靜態變量限定爲僅在本線程內部是靜態的。
實現如下：

public class ThreadSingleton
{
    private ThreadSingleton() { }

    [ThreadStatic] //instance只在當前線程內爲靜態
    private static ThreadSingleton instance;
    public static ThreadSingleton Instance()
    {
        if (instance == null)
        {
            instance = new ThreadSingleton();
        }
        return instance;
    }
}

這裏再不需要線程鎖了，因爲線程級的單例不需要考慮線程安全。
爲了驗證實現的準確性，首先構造一個線程內執行的目標對象：

class Work
{
    public static IList<int> Log = new List<int>();

    /// <summary>
    /// 每個線程的執行部分
    /// </summary>
    public void Procedure()
    {
        ThreadSingleton s1 = ThreadSingleton.Instance();
        ThreadSingleton s2 = ThreadSingleton.Instance();

        //證明可以正常構造實例
        Assert.IsNotNull(s1);
        Assert.IsNotNull(s2);

        //驗證當前線程執行體內兩次獲取的是同一個實例
        Assert.AreEqual(s1.GetHashCode(), s2.GetHashCode());

        //記錄當前線程所使用對象的HashCode
        Log.Add(s1.GetHashCode());
    }
}

這個類會在每個線程內部執行，並驗證線程內多次獲取的Instance是同一個實例，並記錄這個實例的HashCode，以便與別的線程實例對比。
接下來開啓多個線程同時執行Procedure()方法：

[Test]
public void ThreadSingletonTest()
{
    int threadCount = 4;
    Thread[] threads = new Thread[threadCount];  //創建4個線程
    for (int i = 0; i < threadCount; i++)
    {
        ThreadStart work = new ThreadStart(new Work().Procedure);
        threads[i] = new Thread(work);
    }

    //執行線程
    foreach (var thread in threads)
    {
        thread.Start();
    }

    Thread.Sleep(10000);
    Assert.AreEqual(threadCount, Work.Log.Distinct().Count());
}

Work類的靜態變量Log中記錄了每個線程中實例的HashCode，這些HashCode彼此不相同，且與線程的數量一致，證明每個線程間的實例是不相同的。

參考書籍：
王翔著 《設計模式——基於C#的工程化實現及擴展》