設計模式(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#的工程化實現及擴展》