Il thread del costruttore statico C # è sicuro?

In altre parole, questo thread di implementazione di Singleton è sicuro:

public class Singleton
{
    private static Singleton instance;

    private Singleton() { }

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

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

I costruttori statici sono garantiti per essere eseguiti solo una volta per dominio dell'applicazione, prima che vengano create le istanze di una classe o l'accesso ai membri statici. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors

L'implementazione mostrata è thread-safe per la costruzione iniziale, ovvero non è richiesto alcun blocco o test null per costruire l'oggetto Singleton. Tuttavia, ciò non significa che qualsiasi utilizzo dell'istanza sarà sincronizzato. Ci sono molti modi in cui ciò può essere fatto; Ne ho mostrato uno qui sotto.

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

Mentre tutte queste risposte danno la stessa risposta generale, c'è un avvertimento.

Ricorda che tutte le potenziali derivazioni di una classe generica vengono compilate come singoli tipi. Quindi, prestare attenzione quando si implementano costruttori statici per tipi generici.

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

MODIFICARE:

Ecco la dimostrazione:

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

Nella console:

Hit System.Object
Hit System.String

L'uso di un costruttore statico in realtà è thread-safe. Il costruttore statico è garantito per essere eseguito una sola volta.

Dalle specifiche del linguaggio C # :

Il costruttore statico per una classe viene eseguito al massimo una volta in un determinato dominio dell'applicazione. L'esecuzione di un costruttore statico è innescata dal primo dei seguenti eventi che si verificano all'interno di un dominio dell'applicazione:

• Viene creata un'istanza della classe.
• Si fa riferimento a qualsiasi membro statico della classe.

Quindi sì, puoi fidarti che il tuo singleton verrà correttamente istanziato.

Zooba ha sottolineato in modo eccellente (e anche 15 secondi prima di me!) Che il costruttore statico non garantirà l'accesso condiviso sicuro al thread al singleton. Ciò dovrà essere gestito in un altro modo.

Ecco la versione di Cliffnotes dalla pagina MSDN sopra su c # singleton:

Usa sempre il seguente schema, non puoi sbagliare:

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

   private Singleton(){}

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

Oltre alle ovvie caratteristiche di singleton, ti dà queste due cose gratis (rispetto a singleton in c ++):

1. costruzione pigra (o nessuna costruzione se non è mai stata chiamata)
2. sincronizzazione

I costruttori statici sono garantiti per essere attivati ​​una sola volta per dominio app quindi il tuo approccio dovrebbe essere OK. Tuttavia, non è funzionalmente diverso dalla versione in linea più concisa:

private static readonly Singleton instance = new Singleton();

La sicurezza del thread è più un problema quando si inizializzano pigramente cose.

Il costruttore statico terminerà l' esecuzione prima che qualsiasi thread possa accedere alla classe.

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

Il codice sopra ha prodotto i risultati seguenti.

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).

Anche se il costruttore statico impiegava molto tempo a girare, gli altri thread si fermarono e attesero. Tutti i thread leggono il valore di _x impostato nella parte inferiore del costruttore statico.

La specifica di Common Language Infrastructure garantisce che "un inizializzatore di tipo deve essere eseguito esattamente una volta per un determinato tipo, a meno che non sia esplicitamente chiamato dal codice utente". (Sezione 9.5.3.1.) Quindi, a meno che tu non abbia qualche IL bizzarro sulla chiamata libera Singleton ::. Cctor direttamente (improbabile) il tuo costruttore statico verrà eseguito esattamente una volta prima che venga utilizzato il tipo Singleton, verrà creata solo un'istanza di Singleton, e la tua proprietà Instance è thread-safe.

Nota che se il costruttore di Singleton accede alla proprietà Instance (anche indirettamente), la proprietà Instance sarà nulla. Il meglio che puoi fare è rilevare quando ciò accade e generare un'eccezione, controllando che l'istanza non sia nulla nell'accessorio proprietà. Al termine del costruttore statico, la proprietà Instance sarà non nulla.

Come sottolinea la risposta di Zoomba, dovrai rendere Singleton sicuro per accedere da più thread o implementare un meccanismo di blocco usando l'istanza singleton.

Solo per essere pedanti, ma non esiste un costruttore statico, ma piuttosto inizializzatori di tipo statico, ecco una piccola demo della dipendenza ciclica del costruttore statico che illustra questo punto.

Il costruttore statico è garantito per la sicurezza dei thread. Inoltre, dai un'occhiata alla discussione su Singleton su DeveloperZen: http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code -1-discussione /

Sebbene le altre risposte siano per lo più corrette, c'è ancora un altro avvertimento con i costruttori statici.

Ai sensi dell'articolo II.10.5.3.3 Razze e situazioni di stallo del Infrastructure ECMA-335 Common Language

L'inizializzazione del tipo da sola non deve creare un deadlock a meno che un codice chiamato da un inizializzatore di tipo (direttamente o indirettamente) invochi esplicitamente operazioni di blocco.

Il codice seguente provoca un 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();
    }
}

L'autore originale è Igor Ostrovsky, vedi il suo post qui .