Ist der statische C # -Konstruktor-Thread sicher?

Mit anderen Worten, ist dieser Singleton-Implementierungsthread sicher:

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

    static Singleton()
    {
        instance = new Singleton();
    }

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

Statische Konstruktoren werden garantiert nur einmal pro Anwendungsdomäne ausgeführt, bevor Instanzen einer Klasse erstellt oder auf statische Mitglieder zugegriffen wird. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

Die gezeigte Implementierung ist für die anfängliche Konstruktion threadsicher, dh für die Konstruktion des Singleton-Objekts sind keine Sperren oder Nulltests erforderlich. Dies bedeutet jedoch nicht, dass eine Verwendung der Instanz synchronisiert wird. Es gibt verschiedene Möglichkeiten, dies zu tun. Ich habe unten einen gezeigt.

public class Singleton
{
    private static Singleton instance;
    // Added a static mutex for synchronising use of instance.
    private static System.Threading.Mutex mutex;
    private Singleton() { }
    static Singleton()
    {
        instance = new Singleton();
        mutex = new System.Threading.Mutex();
    }

    public static Singleton Acquire()
    {
        mutex.WaitOne();
        return instance;
    }

    // Each call to Acquire() requires a call to Release()
    public static void Release()
    {
        mutex.ReleaseMutex();
    }
}

Während alle diese Antworten die gleiche allgemeine Antwort geben, gibt es eine Einschränkung.

Denken Sie daran, dass alle möglichen Ableitungen einer generischen Klasse als einzelne Typen kompiliert werden. Seien Sie daher vorsichtig, wenn Sie statische Konstruktoren für generische Typen implementieren.

class MyObject<T>
{
    static MyObject() 
    {
       //this code will get executed for each T.
    }
}

BEARBEITEN:

Hier ist die Demonstration:

static void Main(string[] args)
{
    var obj = new Foo<object>();
    var obj2 = new Foo<string>();
}

public class Foo<T>
{
    static Foo()
    {
         System.Diagnostics.Debug.WriteLine(String.Format("Hit {0}", typeof(T).ToString()));        
    }
}

In der Konsole:

Hit System.Object
Hit System.String

Mit eigentlich ein statischer Konstruktor ist THREAD. Der statische Konstruktor wird garantiert nur einmal ausgeführt.

Aus der C # -Sprachenspezifikation :

Der statische Konstruktor für eine Klasse wird in einer bestimmten Anwendungsdomäne höchstens einmal ausgeführt. Die Ausführung eines statischen Konstruktors wird durch das erste der folgenden Ereignisse ausgelöst, die innerhalb einer Anwendungsdomäne auftreten:

• Eine Instanz der Klasse wird erstellt.
• Auf alle statischen Mitglieder der Klasse wird verwiesen.

Ja, Sie können darauf vertrauen, dass Ihr Singleton korrekt instanziiert wird.

Zooba machte einen hervorragenden Punkt (und auch 15 Sekunden vor mir!), Dass der statische Konstruktor keinen thread-sicheren gemeinsamen Zugriff auf den Singleton garantiert. Das muss auf andere Weise gehandhabt werden.

Hier ist die Cliffnotes-Version von der obigen MSDN-Seite auf c # singleton:

Verwenden Sie immer das folgende Muster, Sie können nichts falsch machen:

public sealed class Singleton
{
   private static readonly Singleton instance = new Singleton();

   private Singleton(){}

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

Abgesehen von den offensichtlichen Singleton-Funktionen erhalten Sie diese beiden Dinge kostenlos (in Bezug auf Singleton in C ++):

1. fauler Bau (oder kein Bau, wenn es nie genannt wurde)
2. Synchronisation

Statische Konstruktoren werden garantiert nur einmal pro App-Domäne ausgelöst, daher sollte Ihr Ansatz in Ordnung sein. Es unterscheidet sich jedoch funktional nicht von der prägnanteren Inline-Version:

private static readonly Singleton instance = new Singleton();

Die Thread-Sicherheit ist eher ein Problem, wenn Sie Dinge träge initialisieren.

Der statische Konstruktor wird beendet , bevor ein Thread auf die Klasse zugreifen darf.

    private class InitializerTest
    {
        static private int _x;
        static public string Status()
        {
            return "_x = " + _x;
        }
        static InitializerTest()
        {
            System.Diagnostics.Debug.WriteLine("InitializerTest() starting.");
            _x = 1;
            Thread.Sleep(3000);
            _x = 2;
            System.Diagnostics.Debug.WriteLine("InitializerTest() finished.");
        }
    }

    private void ClassInitializerInThread()
    {
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() starting.");
        string status = InitializerTest.Status();
        System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() status = " + status);
    }

    private void classInitializerButton_Click(object sender, EventArgs e)
    {
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
        new Thread(ClassInitializerInThread).Start();
    }

Der obige Code ergab die folgenden Ergebnisse.

10: ClassInitializerInThread() starting.
11: ClassInitializerInThread() starting.
12: ClassInitializerInThread() starting.
InitializerTest() starting.
InitializerTest() finished.
11: ClassInitializerInThread() status = _x = 2
The thread 0x2650 has exited with code 0 (0x0).
10: ClassInitializerInThread() status = _x = 2
The thread 0x1f50 has exited with code 0 (0x0).
12: ClassInitializerInThread() status = _x = 2
The thread 0x73c has exited with code 0 (0x0).

Obwohl die Ausführung des statischen Konstruktors lange gedauert hat, wurden die anderen Threads angehalten und gewartet. Alle Threads lesen den Wert von _x, der am unteren Rand des statischen Konstruktors festgelegt ist.

Die Common Language Infrastructure-Spezifikation garantiert, dass "ein Typinitialisierer für einen bestimmten Typ genau einmal ausgeführt wird, sofern er nicht ausdrücklich vom Benutzercode aufgerufen wird". (Abschnitt 9.5.3.1.) Wenn Sie also nicht direkt (unwahrscheinlich) eine verrückte IL auf dem losen aufrufenden Singleton ::. Cctor haben, wird Ihr statischer Konstruktor genau einmal ausgeführt, bevor der Singleton-Typ verwendet wird. Es wird nur eine Instanz von Singleton erstellt. und Ihre Instance-Eigenschaft ist threadsicher.

Beachten Sie, dass die Instance-Eigenschaft null ist, wenn der Singleton-Konstruktor (auch indirekt) auf die Instance-Eigenschaft zugreift. Das Beste, was Sie tun können, ist zu erkennen, wann dies geschieht, und eine Ausnahme auszulösen, indem Sie überprüfen, ob die Instanz im Eigenschaften-Accessor nicht null ist. Nach Abschluss Ihres statischen Konstruktors ist die Instance-Eigenschaft nicht null.

Wie die Antwort von Zoomba zeigt, müssen Sie Singleton für den Zugriff von mehreren Threads sicher machen oder einen Sperrmechanismus für die Verwendung der Singleton-Instanz implementieren.

Nur um pedantisch zu sein, aber es gibt keinen statischen Konstruktor, sondern statische Typinitialisierer. Hier ist eine kleine Demo der Abhängigkeit von zyklischen statischen Konstruktoren, die diesen Punkt veranschaulicht.

Der statische Konstruktor ist garantiert threadsicher. Schauen Sie sich auch die Diskussion über Singleton unter DeveloperZen an: http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code-1-discussion/

Obwohl andere Antworten größtenteils richtig sind, gibt es noch eine weitere Einschränkung bei statischen Konstruktoren.

Gemäß Abschnitt II.10.5.3.3 Rennen und Deadlocks der ECMA-335 Common Language Infrastructure

Die Typinitialisierung allein darf keinen Deadlock erzeugen, es sei denn, ein von einem Typinitialisierer (direkt oder indirekt) aufgerufener Code ruft explizit Blockierungsvorgänge auf.

Der folgende Code führt zu einem Deadlock

using System.Threading;
class MyClass
{
    static void Main() { /* Won’t run... the static constructor deadlocks */  }

    static MyClass()
    {
        Thread thread = new Thread(arg => { });
        thread.Start();
        thread.Join();
    }
}

Der ursprüngliche Autor ist Igor Ostrovsky, siehe seinen Beitrag hier .