目錄
- 介紹
- 第一個版本 ——不是執行緒安全的
- 第二個版本 —— 簡單的執行緒安全
- 第三個版本 - 使用雙重檢查鎖定嘗試執行緒安全
- 第四個版本 - 不太懶，不使用鎖且執行緒安全
- 第五版 - 完全懶惰的實體化
- 第六版 - 使用.NET 4的 Lazy 型別
- 性能與懶惰
- 例外
- 結論
介紹
單例模式是軟體工程中最著名的模式之一，從本質上講，單例是一個只允許創建自身的單個實體的類，并且通常可以簡單地訪問該實體，最常見的是，單例不允許在創建實體時指定任何引數——否則對實體的第二個請求但具有不同的引數可能會有問題！（如果對于具有相同引數的所有請求都應訪問相同的實體，則工廠模式更合適，）本文僅處理不需要引數的情況，通常，單例的要求是它們是懶惰地創建的——即直到第一次需要時才創建實體，
在C＃中實作單例模式有各種不同的方法，我將以優雅的相反順序呈現它們，從最常見的、不是執行緒安全的版本開始，一直到完全延遲加載的、執行緒安全的、簡單且高性能的版本，
然而，所有這些實作都有四個共同特征：
- 單個建構式，它是私有且無引數的，這可以防止其他類實體化它（這將違反模式），請注意，它還可以防止子類化——如果一個單例物件可以被子類化一次，那么它就可以被子類化兩次，如果每個子類都可以創建一個實體，則違反了該模式，如果您需要基型別的單個實體，則可以使用工廠模式，但是確切的型別要到運行時才能知道，
- 類是密封的，嚴格來說，由于上述原因，這是不必要的，但是可以幫助JIT進行更多的優化，
- 一個靜態變數，用于保存對單個已創建實體的參考（如果有的話），
- 公共靜態意味著獲取對單個已創建實體的參考，必要時創建一個實體，
請注意，所有這些實作還使用公共靜態屬性Instance 作為訪問實體的方法，在所有情況下，可以輕松地將屬性轉換為方法，而不會影響執行緒安全性或性能，
第一個版本 ——不是執行緒安全的
// 糟糕的代碼！不要使用！ 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，然后兩個都創建實體，這違反了單例模式，請注意，實際上，在計算運算式之前可能已經創建了實體，但是記憶體模型不保證其他執行緒可以看到實體的新值，除非已經傳遞了合適的記憶體屏障（互斥鎖），
第二個版本 —— 簡單的執行緒安全
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)，而是鎖定了類私有的靜態變數的值，鎖定其他類可以訪問和鎖定的物件（例如型別）會導致性能問題甚至死鎖，這是我的風格偏好——只要有可能，只鎖定專門為鎖定目的而創建的物件，或者為了特定目的（例如，等待/觸發佇列）而鎖定的檔案，通常這些物件應該是它們所使用的類的私有物件，這有助于使撰寫執行緒安全的應用程式變得更加容易，
第三個版本 - 使用雙重檢查鎖定嘗試執行緒安全
// 糟糕的代碼！不要使用！ 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變得有效，就像明確的記憶體屏障呼叫一樣，盡管在后一種情況下，甚至專家也無法準確地就需要哪些屏障達成一致，我盡量避免專家對對錯意見也不一致的情況！ - 這很容易出錯，該模式需要完全如上所述——任何重大變化都可能影響性能或正確性，
- 它的性能仍然不如后續的實作，
第四個版本 - 不太懶，不使用鎖且執行緒安全
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行內可能會使性能相同，（注意，如果您需要懶惰的，靜態建構式本身仍然是必需的，）
第五版 - 完全懶惰的實體化
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運算式最容易做到這一點，
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，）
轉載地址：https://www.cnblogs.com/leolion/p/10241822.html
原文作者：Jon Skeet
原文地址：Implementing the Singleton Pattern in C#
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/224937.html
標籤：設計模式