單例模式 線程安全的Singleton 會破壞Singleton的情況 線程級Singleton 單例模式是幾個創建型模式中最獨立的一個，它的主要目標不是根據客戶程式調用生成一個新的實例，而是控制某個類型的實例數量只有一個。 GOF對單例的描述為： Ensure a class only has o ...
- 單例模式
- 線程安全的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#的工程化實現及擴展》
