Implementierung des C#-Singleton-Musters und Beispiele für Leistungsvergleiche

In diesem Artikel werden hauptsächlich relevante Informationen zur Implementierung und zum Leistungsvergleich des C#-Singleton-Modus vorgestellt. Freunde in Not können sich auf die

Einführung

Ein Singleton bezieht sich auf eine Klasse, die nur eine Instanz haben kann (genauer gesagt handelt es sich in C# um eine Klasse, die in jeder AppDomain nur eine Instanz haben kann). Sie wird in der Softwareentwicklung verwendet. Einer der häufigsten Modi. Nachdem der erste Benutzer eine Instanz dieser Klasse erstellt hat, können nachfolgende Benutzer, die diese Klasse verwenden müssen, nur die zuvor erstellte Instanz verwenden und können keine neue Instanz erstellen, wenn sie zum ersten Mal verwendet wird Mehrere Singleton-Implementierungsmethoden in C# und Analyse der Thread-Sicherheits- und Leistungsunterschiede zwischen ihnen ineffizient) zu einer Lazy-Loadable-, Thread-sicheren und effizienten Implementierung, sie alle haben einige grundlegende Dinge gemeinsam:

Singleton-Klassen haben nur einen privaten parameterlosen Konstruktor

• Die Klasse wird als versiegelt deklariert (nicht erforderlich)

• Es gibt eine statische Variable in der Klasse, die einen Verweis auf die erstellte Instanz enthält

• Die Singleton-Klasse stellt eine statische Methode oder Eigenschaft bereit, um einen Verweis auf die erstellte Instanz zurückzugeben (z. B. GetInstance)
Mehrere Implementierungen

Ein nicht-Thread-sicher

Diese Methode ist nicht Thread-sicher, es werden zwei Threads gleichzeitig ausgeführt, wenn (Instanz == null). und das Erstellen zweier verschiedener Instanzen ersetzt die neu erstellte, wodurch die zuvor erhaltene Referenz leer ist >

Zweite einfache Thread-sichere Implementierung

//Bad code! Do not use!
public sealed class Singleton
{
  private static Singleton instance = null;
  private Singleton()
  {
  }

  public static Singleton instance
  {
    get
    {
      if (instance == null)
      {
        instance = new Singleton();
      }
      return instance;
    }
  }
}

Verglichen mit Implementierung eins, diese Version fügt eine Sperre für die Instanz hinzu. Dies vermeidet Thread-Konflikte in der ersten Implementierung. Da die Sperre jedoch jedes Mal verwendet wird Wenn die Instanz aufgerufen wird und die Kosten für den Aufruf der Sperre hoch sind, führt diese Implementierung zu einem gewissen Leistungsverlust. Beachten Sie, dass wir hier ein neues privates Objektinstanz-Vorhängeschloss verwenden, um den Sperrvorgang nicht direkt zu implementieren Das direkte Sperren des Typs birgt Risiken, da er theoretisch in jedem Code aufgerufen werden kann.

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;
      }
    }
  }
}

Hinweis : In C# kann derselbe Thread mehrere Vorgänge für ein Objekt ausführen. Er wird einmal gesperrt. Wenn jedoch verschiedene Threads gleichzeitig gesperrt werden, kann es zu Thread-Wartezeiten oder einem schwerwiegenden Deadlock kommen. Wenn wir Sperren verwenden, versuchen wir daher, private Variablen in der Klasse zu sperren, um die obige Situation zu vermeiden.

Thread-sichere Implementierung der dreifachen doppelten Überprüfung

Während die Thread-Sicherheit gewährleistet ist, vermeidet diese Implementierung auch den Sperrvorgang bei jedem Instanzaufruf, was auch der Fall ist eine gewisse Zeit sparen. Diese Implementierung hat jedoch auch Nachteile:

public sealed calss 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;
    }
  } 
}

1 funktioniert nicht in Java. (Die konkreten Gründe sind im Originaltext zu finden, aber ich verstehe hier nicht viel)

2 Programmierer können bei der eigenen Implementierung leicht Fehler machen. Wenn Sie in diesem Modus eigene Änderungen am Code vornehmen, seien Sie sehr vorsichtig, da die Logik der doppelten Überprüfung relativ komplex ist und es aufgrund mangelnder Denkweise leicht zu Fehlern kommen kann.

Vier Thread-sichere Implementierungen ohne Sperren

Diese Implementierung ist sehr einfach und verwendet keine Sperren, ist aber dennoch Thread-sicher. Hier wird eine statische, schreibgeschützte Singleton-Instanz verwendet. Wenn die Singleton-Instanz zum ersten Mal aufgerufen wird, wird sie direkt von .NET gesteuert Und es wird nur einmal in einer AppDomaing erstellt.

Diese Implementierung hat auch einige Nachteile:

public sealed class Singleton
{
  //在Singleton第一次被调用时会执行instance的初始化
  private static readonly Singleton instance = new Singleton();

  //Explicit static consturctor to tell C# compiler 
  //not to mark type as beforefieldinit
  static Singleton()
  {
  }

  private Singleton()
  {
  }

  public static Singleton Instance
  {
    get
    {
      return instance;
    }
  }
}

1 Der Zeitpunkt der Erstellung der Instanz ist unbekannt und jeder Aufruf an Singleton erstellt die Instanz im Voraus

2 Schleifenaufrufe des statischen Konstruktors. Wenn es zwei Klassen A und B gibt, den statischen Konstruktor von A, der B aufruft, und den statischen Konstruktor von B, der A aufruft, bilden diese beiden einen zirkulären Aufruf, der ernsthaft zum Absturz des Programms führen kann. 3 Wir müssen den statischen Konstruktor von Singleton manuell hinzufügen, um sicherzustellen, dass der Singleton-Typ nicht automatisch mit dem beforefieldinit-Attribut hinzugefügt wird, um sicherzustellen, dass die Instanz erstellt wird, wenn Singleton zum ersten Mal aufgerufen wird. 4Das schreibgeschützte Attribut kann zur Laufzeit nicht geändert werden. Wenn wir die Instanz verwerfen und eine neue Instanz neu erstellen müssen, während das Programm ausgeführt wird, kann diese Implementierungsmethode nicht erfüllt werden.

Fünf vollständig verzögerte Instanziierung

Implementierung fünf ist ein Wrapper für Implementierung vier. Dadurch wird sichergestellt, dass die Instanz nur in der get-Methode von Instance aufgerufen und nur vor dem ersten Aufruf initialisiert wird. Es handelt sich um eine Version der Implementierung 4, die Lazy Loading gewährleistet.

Six verwendet den Lazy-Typ

public sealed class Singleton
{
  private Singleton()
  {
  }

  public static Singleton Instance 
  {
    get
    {
      return Nested.instance;
    }
  }

  private class Nested
  {
    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static Nested()
    {
    }

    internal static readonly Singleton instance = new Singleton();
  }
}

.NET4 oder höher unterstützt Lazy Der Code gewährleistet die Thread-Sicherheit und die Lazy-Loading-Eigenschaften des Singletons.

Leistungsunterschied

In der vorherigen Implementierung haben wir den Schwerpunkt auf die Thread-Sicherheit und das verzögerte Laden des Codes gelegt. Wenn die Initialisierung Ihrer Singleton-Klasse jedoch im tatsächlichen Einsatz kein zeitaufwändiger Vorgang ist oder die Initialisierungssequenz keine Fehler verursacht, ist die verzögerte Initialisierung eine entbehrliche Funktion, da die für die Initialisierung benötigte Zeit vernachlässigbar ist.

Wenn Ihre Singleton-Instanz in tatsächlichen Nutzungsszenarien häufig aufgerufen wird (z. B. in einer Schleife), ist der Leistungsverbrauch, der durch die Gewährleistung der Thread-Sicherheit verursacht wird, stärker zu berücksichtigen.

Um die Leistung dieser Implementierungen zu vergleichen, habe ich einen kleinen Test durchgeführt, bei dem ich die Singletons in diesen Implementierungen 900 Millionen Mal durchlaufen habe und jedes Mal die Instanzmethode aufgerufen habe, um eine count++-Operation auszuführen, jede Million einmal ausgegeben , die Ausführungsumgebung ist Visual Studio für Mac auf MBP. Die Ergebnisse sind wie folgt:

	线程安全性	延迟加载	测试运行时间(ms)
实现一	否	是	15532
实现二	是	是	45803
实现三	是	是	15953
实现四	是	不完全	14572
实现五	是	是	14295
实现六	是	是	22875

Die Testmethode ist nicht streng, aber es ist dennoch ersichtlich, dass Methode zwei die zeitaufwändigste ist, da jedes Mal, fast dreimal, die Sperre aufgerufen werden muss so lange wie die anderen. An zweiter Stelle steht die Implementierung mit dem .NET-Lazy-Typ, der etwa die Hälfte mehr als die anderen ist. Die übrigen vier weisen keine offensichtlichen Unterschiede auf.

Zusammenfassung

Im Allgemeinen unterscheiden sich die verschiedenen oben genannten Singleton-Implementierungsmethoden unter der heutigen Computerleistung nicht sehr, es sei denn, Sie benötigen besonders viel Parallelität Bei der Aufrufinstanz müssen Sie Probleme mit der Sperrleistung berücksichtigen.

Für normale Entwickler ist es gut, Methode 2 oder Methode 6 zu verwenden, um Singletons zu implementieren. Die Methoden 4 und 5 erfordern ein gutes Verständnis des C#-Laufprozesses und der Implementierung. Sie erfordern bestimmte Fähigkeiten und die Zeit, die sie sparen ist noch begrenzt.

Zitat

Der größte Teil dieses Artikels wurde aus Implementing the Singleton Pattern in C# übersetzt, wobei einige meiner eigenen Erkenntnisse hinzugefügt wurden. Das ist mir aufgefallen, als ich nach „statischer schreibgeschützter Feldinitialisierer vs. statischer Konstruktorinitialisierung“ gesucht habe. Ich möchte den beiden Autoren hier meinen Dank aussprechen.

Das obige ist der detaillierte Inhalt vonImplementierung des C#-Singleton-Musters und Beispiele für Leistungsvergleiche. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!