• 單例模式
• 執行緒安全的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#的工程化實現及擴充套件》