- 單例模式
- 執行緒安全的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#的工程化實作及擴展》
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/4539.html
標籤：設計模式
上一篇：設計模式(1) 工廠方法模式
下一篇：中介者模式