Quali sono i pericoli dell'utilizzo di Singleton in un'applicazione multithreading

Question

Sto cercando di utilizzare un singleton in un servizio Win con multithreading per eseguire la registrazione e volevo sapere quali sono alcuni dei problemi che potrei incontrare. Ho già impostato l'istanza get per gestire la sincronizzazione con

private static volatile Logging _instance; 
    private static object _syncRoot = new object(); 

    private Logging(){} 
    public static Logging Instance 
    { 
     get 
     { 
      if (_instance==null) 
      { 
       lock(_syncRoot) 
       { 
        if (_instance == null) 
        { 
         _instance = new Logging(); 
        } 
       } 
      } 
      return _instance; 
     } 
    } 

C'è qualcos'altro di cui potrei aver bisogno di preoccuparmi?

Answer 1

Mi sembra abbastanza buono.

Vedere Implementing the Singleton Pattern in C# per ulteriori informazioni.

Modifica: Probabilmente dovrebbe inserire il ritorno all'interno del blocco, però.

Answer 2

Penso che se i metodi di istanza di Logging sono thread-safe non c'è nulla di cui preoccuparsi.

Answer 3

Singleton ha il potenziale per diventare un collo di bottiglia per l'accesso alla risorsa incorporata dalla classe e forzare l'accesso sequenziale a una risorsa che potrebbe altrimenti essere utilizzata in parallelo.

In questo caso, potrebbe non essere una cosa negativa, perché non desideri che più elementi vengano scritti nel tuo file nello stesso istante, e anche così non penso che la tua implementazione abbia quel risultato. Ma è qualcosa di cui essere consapevole.

Answer 4

Si sta utilizzando double-checked locking ciò che è considerato un anti-modello. Wikipedia ha schemi con e senza inizializzazione pigra per lingue diverse.

Dopo aver creato l'istanza di singleton, è necessario assicurarsi che tutti i metodi siano sicuri per i thread.

Answer 5

Questo è più informativo di qualsiasi altra cosa.

Quello che hai postato è il ricontrollato algoritmo bloccaggio - e quello che hai postato volontà lavoro, per quanto ne sono a conoscenza. (A partire da Java 1.5 funziona anche lì.) Tuttavia, è molto fragile - se si riesce a sbagliare, si potrebbero introdurre condizioni di gara molto sottili.

io di solito preferisco inizializzare il Singleton nel inizializzatore statico: (. Aggiungere un costruttore statico, se si desidera un po 'di pigrizia in più)

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

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

    private Singleton() 
    { 
     // Do stuff 
    } 
} 

che è più facile pattern per ottenere il diritto, e nella maggior parte dei casi lo fa altrettanto bene.

C'è più dettagli sul mio C# singleton implementation page (collegato anche da Michael).

Per quanto riguarda i pericoli, direi che il problema più grande è che si perde la testabilità. Probabilmente no non valido per la registrazione.

Answer 6

Un suggerimento migliore sarebbe quello di stabilire il logger in una fase di installazione a thread singolo, quindi è garantito essere lì quando ne hai bisogno. In un servizio di Windows, OnStart è un ottimo posto per farlo.

Un'altra opzione è utilizzare System.Threading.Interlocked.CompareExchange (T%, T, T): metodo T per uscire. È meno confuso ed è garantito che funzioni.

System.Threading.Interlocked.CompareExchange<Logging>(_instance, null, new Logging()); 

Answer 7

è necessario assicurarsi che ogni metodo nel registratore sono sicuro eseguire contemporaneamente, cioè che non scrivono allo stato condivisa senza il bloccaggio.

Answer 8

C'è un po 'di dibattito in merito alla necessità di eseguire il primo controllo per null use Thread.VolatileRead() se si utilizza lo schema di blocco a doppio controllo e si desidera che funzioni su tutti i modelli di memoria. Un esempio del dibattito può essere letto allo http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/b1932d46-877f-41f1-bb9d-b4992f29cedc/.

Detto questo, di solito uso la soluzione di Jon Skeet dall'alto.