【譯】深入理解C#——在C#中實現單例模式

来源:https://www.cnblogs.com/leolion/archive/2019/01/09/10241822.html
-Advertisement-
Play Games

單例模式是軟體工程中最著名的模式之一。從本質上講,單例是一個只允許創建自身的單個實例的類,並且通常可以簡單地訪問該實例。最常見的是,單例不允許在創建實例時指定任何參數——否則對實例的第二個請求但具有不同的參數可能會有問題!(如果對於具有相同參數的所有請求都應訪問相同的實例,則工廠模式更合適。)本文... ...


目錄

介紹

單例模式是軟體工程中最著名的模式之一。從本質上講,單例是一個只允許創建自身的單個實例的類,並且通常可以簡單地訪問該實例。最常見的是,單例不允許在創建實例時指定任何參數——否則對實例的第二個請求但具有不同的參數可能會有問題!(如果對於具有相同參數的所有請求都應訪問相同的實例,則工廠模式更合適。)本文僅處理不需要參數的情況。通常,單例的要求是它們是懶惰地創建的——即直到第一次需要時才創建實例。

在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。)

原文作者:Jon Skeet

原文地址:Implementing the Singleton Pattern in C#

wif 項目代碼:https://github.com/LeoYang610/wif


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • $('#a')是返回一個jquery對象 $('#a')[0]是一個element對象 document.getElementById('a') return 一個element對象 ...
  • 微信小程式更新以後今天<radio>全部變成垂直排列了,佈局亂了。 一開始嘗試給外層<view>添加display:flex;flex-direction:row;未果。 後來在開發者社區查找,發現是微信更新後的bug,很多線上的項目都受影響了。 解決: 1、在<radio-group>里添加包一個 ...
  • 分析: 外層邊框是瀏覽器邊框,內部盒子是頁面的一個盒子,綠點是盒子中滑鼠的位置。滑鼠相對盒子邊框的坐標=頁面中(註意不是瀏覽器)滑鼠坐標-盒子相對於瀏覽器邊框的偏移量 第一步:求瀏覽器邊框位置 x=element.offsetLeft; y=element.offsetTop; 代碼如下: 第二步: ...
  • 把data裡面需要回顯的欄位,加入一個數組arr,然後用後臺傳過來的json里的數據,迴圈json去判定arr裡面有沒有沒有當前的對象的key,如果有就 ...
  • window 10 python 3 安裝flask 首先打開cmd命令執行視窗切換到Python安裝目錄的Script,輸入pip出現以下頁面 這裡我們使用virtualenv虛擬開發環境 為什麼使用virtualenv? 1、使用不同應用開發環境獨立開發 2、環境升級不影響其他應用,也不會影響全 ...
  • Redis中的大集合對象,如set、zset等,如果有上千萬個元素,一般是不能直接用del命令來刪除的,因為del命令可能會耗時幾秒鐘,而redis本身是單線程的,在高併發的情況下會阻塞大量的請求,嚴重時可能引起雪崩。 那我們要怎麼來刪除它呢? 這裡我們給出一個解決方案,即結合lua腳本來實現刪除大 ...
  • 從json-lib轉成jackson的遇到的問題 問題一:json 字元串,再經過Jackson序列化之後就變成原生字元串了。而json-lib經過再序列化之後,還是json格式的串。 針對這種情況,可以寫一個Serializer類,遇到json串的時候就當作原生字元串寫入即可。 <<JsonStr ...
  • 橋接適用於把抽象化和實現化解耦,使得二者可以獨立變化。這種類型的設計模式屬於結構性模式,它通過提供抽象化和實現化之間的橋接結構,來實現二者的解耦 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...