介紹#
單例模式是軟件工程中最着名的模式之一。從本質上講，單例是一個只允許創建自身的單個實例的類，並且通常可以簡單地訪問該實例。最常見的是，單例不允許在創建實例時指定任何參數——否則對實例的第二個請求但具有不同的參數可能會有問題！（如果對於具有相同參數的所有請求都應訪問相同的實例，則工廠模式更合適。）本文僅處理不需要參數的情況。通常，單例的要求是它們是懶惰地創建的——即直到第一次需要時才創建實例。
在C＃中實現單例模式有各種不同的方法。我將以優雅的相反順序呈現它們，從最常見的、不是線程安全的版本開始，一直到完全延遲加載的、線程安全的、簡單且高性能的版本。
然而，所有這些實現都有四個共同特徵：
- 單個構造函數，它是私有且無參數的。這可以防止其他類實例化它（這將違反模式）。請注意，它還可以防止子類化——如果一個單例對象可以被子類化一次，那麼它就可以被子類化兩次，如果每個子類都可以創建一個實例，則違反了該模式。如果您需要基類型的單個實例，則可以使用工廠模式，但是確切的類型要到運行時才能知道。
- 類是密封的。嚴格來說，由於上述原因，這是不必要的，但是可以幫助JIT進行更多的優化。
- 一個靜態變量，用於保存對單個已創建實例的引用（如果有的話）。
- 公共靜態意味着獲取對單個已創建實例的引用，必要時創建一個實例。
請注意，所有這些實現還使用公共靜態屬性Instance 作爲訪問實例的方法。在所有情況下，可以輕鬆地將屬性轉換爲方法，而不會影響線程安全性或性能。
第一個版本 ——不是線程安全的#
Copy
// 糟糕的代碼！不要使用！ public sealed class Singleton { private static Singleton instance = null ; private Singleton（） { } public static Singleton Instance { get { if （instance == null） { instance = new Singleton（）; } return instance; } } }
如前所述，上述內容不是線程安全的。兩個不同的線程都可以評估測試if (instance==null)並發現它爲true，然後兩個都創建實例，這違反了單例模式。請注意，實際上，在計算表達式之前可能已經創建了實例，但是內存模型不保證其他線程可以看到實例的新值，除非已經傳遞了合適的內存屏障（互斥鎖）。
第二個版本 —— 簡單的線程安全#
Copy
public sealed class Singleton { private static Singleton instance = null; private static readonly object padlock = new object(); Singleton() { } public static Singleton Instance { get { lock (padlock) { if (instance == null) { instance = new Singleton(); } return instance; } } } }
此實現是線程安全的。線程取消對共享對象的鎖定，然後在創建實例之前檢查是否已創建實例。這會解決內存屏障問題（因爲鎖定確保在獲取鎖之後邏輯上發生所有讀取，並且解鎖確保在鎖定釋放之前邏輯上發生所有寫入）並確保只有一個線程將創建實例（僅限於一次只能有一個線程可以在代碼的那一部分中——當第二個線程進入它時，第一個線程將創建實例，因此表達式將計算爲false）。不幸的是，每次請求實例時都會獲得鎖定，因此性能會受到影響。
請注意，我沒有像這個實現的某些版本那樣鎖定typeof(Singleton)，而是鎖定了類私有的靜態變量的值。鎖定其他類可以訪問和鎖定的對象（例如類型）會導致性能問題甚至死鎖。這是我的風格偏好——只要有可能，只鎖定專門爲鎖定目的而創建的對象，或者爲了特定目的（例如，等待/觸發隊列）而鎖定的文檔。通常這些對象應該是它們所使用的類的私有對象。這有助於使編寫線程安全的應用程序變得更加容易。
第三個版本 - 使用雙重檢查鎖定嘗試線程安全#
Copy
// 糟糕的代碼！不要使用！ public sealed class Singleton { private static Singleton instance = null; private static readonly object padlock = new object(); Singleton() { } public static Singleton Instance { get { if (instance == null) { lock (padlock) { if (instance == null) { instance = new Singleton(); } } } return instance; } } }
該實現嘗試是線程安全的，而不必每次都取出鎖。不幸的是，該模式有四個缺點：
- 它在Java中不起作用。這似乎是一個奇怪的事情，但是如果您需要Java中的單例模式，這是值得知道的，C＃程序員也可能是Java程序員。Java內存模型無法確保構造函數在將新對象的引用分配給
Instance之前完成。Java內存模型經歷了1.5版本的重新改進，但是在沒有volatile變量（如在C＃中）的情況下，雙重檢查鎖定仍然會被破壞。 - 在沒有任何內存障礙的情況下，ECMA CLI規範也打破了這一限制。有可能在.NET 2.0內存模型（比ECMA規範更強）下它是安全的，但我寧願不依賴那些更強大的語義，特別是如果對安全性有任何疑問的話。使
instance變量volatile變得有效，就像明確的內存屏障調用一樣，儘管在後一種情況下，甚至專家也無法準確地就需要哪些屏障達成一致。我儘量避免專家對對錯意見也不一致的情況！ - 這很容易出錯。該模式需要完全如上所述——任何重大變化都可能影響性能或正確性。
- 它的性能仍然不如後續的實現。
第四個版本 - 不太懶，不使用鎖且線程安全#
Copy
public sealed class Singleton { private static readonly Singleton instance = new Singleton(); // 顯式靜態構造函數告訴C＃編譯器 // 不要將類型標記爲BeforeFieldInit static Singleton() { } private Singleton() { } public static Singleton Instance { get { return instance; } } }
正如您所看到的，這實際上非常簡單——但是爲什麼它是線程安全的，它有多懶惰？C＃中的靜態構造函數僅在創建類的實例或引用靜態成員時執行，並且每個AppDomain只執行一次。考慮到無論發生什麼情況，都需要執行對新構造的類型的檢查，這比在前面的示例中添加額外檢查要快。然而，還有一些小缺陷：
- 它並不像其他實現那樣懶惰。特別是，如果您有
Instance之外的靜態成員，那麼對這些成員的第一次引用將涉及到創建實例。這將在下一個實現中得到糾正。 - 如果一個靜態構造函數調用另一個靜態構造函數，而另一個靜態構造函數再次調用第一個構造函數，則會出現複雜情況。查看.NET規範（目前是分區II的第9.5.3節），瞭解有關類型初始化器的確切性質的更多詳細信息——它們不太可能會影響您，但是有必要了解靜態構造函數在循環中相互引用的後果。
- 類型初始化器的懶惰性只有在.NET沒有使用名爲
BeforeFieldInit的特殊標誌標記類型時才能得到保證。不幸的是，C＃編譯器（至少在.NET 1.1運行時中提供）將所有沒有靜態構造函數的類型（即看起來像構造函數但被標記爲靜態的塊）標記爲BeforeFieldInit。我現在有一篇文章，詳細介紹了這個問題。另請注意，它會影響性能，如在頁面底部所述的那樣。
您可以使用此實現（並且只有這一個）的一個快捷方式是將 Instance作爲一個公共靜態只讀變量，並完全刪除該屬性。這使得基本的框架代碼非常小！然而，許多人更願意擁有一個屬性，以防將來需要採取進一步行動，而JIT內聯可能會使性能相同。（注意，如果您需要懶惰的，靜態構造函數本身仍然是必需的。）
第五版 - 完全懶惰的實例化#
Copy
public sealed class Singleton { private Singleton() { } public static Singleton Instance { get { return Nested.instance; } } private class Nested { // 顯式靜態構造告訴C＃編譯器 // 未標記類型BeforeFieldInit static Nested() { } internal static readonly Singleton instance = new Singleton(); } }
在這裏，實例化是由對嵌套類的靜態成員的第一次引用觸發的，該引用只發生在Instance中。這意味着實現是完全懶惰的，但是具有前面實現的所有性能優勢。請注意，儘管嵌套類可以訪問封閉類的私有成員，但反之則不然，因此需要instance在此處爲內部成員。不過，這不會引起任何其他問題，因爲類本身是私有的。但是，爲了使實例化變得懶惰，代碼要稍微複雜一些。
第六版 - 使用.NET 4的 Lazy 類型#
如果您使用的是.NET 4（或更高版本），則可以使用 System.Lazy 類型使惰性變得非常簡單。您需要做的就是將委託傳遞給調用Singleton構造函數的構造函數——使用lambda表達式最容易做到這一點。
Copy
public sealed class Singleton { private static readonly Lazy<Singleton> lazy = new Lazy<Singleton>(() => new Singleton()); public static Singleton Instance { get { return lazy.Value; } } private Singleton() { } }
它很簡單，而且性能很好。它還允許您檢查是否已使用IsValueCreated 屬性創建實例（如果需要的話）。
上面的代碼隱式地將LazyThreadSafetyMode.ExecutionAndPublication用作Lazy<Singleton>的線程安全模式。根據您的要求，您可能希望嘗試其他模式。
性能與懶惰#
在許多情況下，您實際上並不需要完全懶惰——除非您的類初始化做了一些特別耗時的事情，或者在其他地方產生了一些副作用，否則最好忽略上面所示的顯式靜態構造函數。這可以提高性能，因爲它允許JIT編譯器進行一次檢查（例如在方法的開頭）以確保類型已經初始化，然後從那時開始設定它。如果在相對緊密的循環中引用單例實例，則會產生（相對）顯著的性能差異。您應該決定是否需要完全延遲實例化，並在類中適當地記錄此決策。
這個頁面存在的很多原因是人們試圖變得聰明，因此提出了雙重檢查鎖定算法。我們常常認爲鎖定是昂貴的，這被誤導的。我寫了一個非常快速的基準測試，在一個循環中獲取10億次單例實例，並嘗試不同的變體。這並不是很科學，因爲在現實生活中，您可能想知道如果每次迭代都涉及到對獲取單例的方法的調用，那麼速度有多快。然而這確實顯示了一個重要的觀點。在我的筆記本電腦上，最慢的解決方案（大約5倍）是鎖定解決方案（解決方案2）。這很重要嗎？可能不會，當您記住它仍然能夠在40秒內獲取10億次Singleton。（注意：這篇文章最初是在很久以前寫的——現在我希望有更好的性能。）這意味着，如果你是“僅僅”每秒獲得40萬次單例實例，那麼花費的成本將是1％的性能——所以不會做很多事情去改進它。現在，如果你經常 獲得單例實例——你是否可能在循環中使用它？如果您非常關心如何提高性能，爲什麼不在循環外聲明一個局部變量，先獲取一次Singleton，然後再循環呢。Bingo，即使是最慢的實現性能也足夠了。
我非常有興趣看到一個真實的應用程序，在這個應用程序中，使用簡單鎖定和使用一種更快的解決方案之間的差異實際上會帶來顯著的性能差異。
異常#
有時，您需要在單例構造函數中執行一些操作，這可能會拋出異常，但可能不會對整個應用程序造成致命影響。您的應用程序可能能夠解決此問題，並希望再次嘗試。在這個階段，使用類型初始化器來構造單例會出現問題。不同的運行時處理這種情況的方式不同，但我不知道有哪些運行時執行了所需的操作（再次運行類型初始化程序），即使有一個運行時這樣做，您的代碼也會在其他運行時被破壞。爲了避免這些問題，我建議使用文章裏列出的第二種模式 ——只需使用一個簡單的鎖，並每次都進行檢查，如果尚未成功構建實例，則在方法/屬性中構建實例。
結論#
在C＃中實現單例模式有各種不同的方法。讀者已經寫信給我詳細說明了他已經封裝了同步方面的方法，雖然我承認這可能在一些非常特殊的情況下有用（特別是在你想要非常高性能的地方，以及確定單例是否已經創建，並完全懶惰，而不考慮其他靜態成員被調用）。我個人並不認爲這種情況會經常出現，值得在這篇文章中進一步改進，但如果你處於這種情況，請發郵件給我。
我的個人的偏好是解決方案4：我通常唯一一次不採用它是因爲我需要能夠在不觸發初始化的情況下調用其他靜態方法，或者如果我需要知道單例是否已經被實例化。我不記得上次我處於那種情況是什麼時候了，假設我有過，在那種情況下，我可能會選擇解決方案2，這仍然是很好的，很容易正確實現。
解決方案5很優雅，但是比2或4更復雜，正如我上面所說，它提供的好處似乎只是很少有用。解決方案6是一種更簡單的方法來實現懶惰，如果你使用.NET 4.它還有一個優勢，它顯然是懶惰的。我目前仍然傾向於使用解決方案4，這僅僅是出於習慣——但如果我與沒有經驗的開發人員合作，我很可能會選擇解決方案6作爲一種簡單且普遍適用的模式。
（我不會使用解決方案1，因爲它是有缺陷的，我也不會使用解決方案3，因爲它的好處沒有超過5。）
原文作者：Jon Skeet