Singleton con volatili in Java

Question

class MyClass 
{ 
     private static volatile Resource resource; 

     public static Resource getInstance() 
     { 
      if(resource == null) 
        resource = new Resource(); 
      return resource; 
     } 
} 

Ecco il mio dubbio è secondo a Java concorrenza in pratica se si utilizza volatile, la pubblicazione sicura accade (vale a dire non appena il riferimento è visibile a un altro thread i dati sono anche disponibili). Quindi posso usarlo qui? Ma se è corretto, supponiamo che thread1 ora controlli "resource" ed è null, quindi inizia a creare l'oggetto. Mentre thread1 sta creando l'oggetto di un altro thread, ad esempio thread2, viene e inizia a controllare il valore di "resource" e thread2 lo trova come null (supponiamo che la creazione dell'oggetto "resource" richieda una notevole quantità di tempo e poiché thread1 non ha ancora completato la creazione la pubblicazione sicura non è avvenuta quindi non disponibile per thread2) quindi inizierà anche a creare l'oggetto? se sì, allora le rotture invarianti di classe. Ho ragione? Per favore aiutami a capire questo uso speciale di volatile qui.

Answer 1

volatile risolve un problema che è problema di visibilità. Se si sta scrivendo a una variabile dichiarata volatile, il valore sarà immediatamente visibile all'altro thread. Come tutti sappiamo abbiamo un diverso livello di cache in OS L1, L2, L3 e se scriviamo su una variabile in un thread non è garantito che sia visibile ad altri, quindi se usiamo volatile scrive per dirigere la memoria ed è visibile per gli altri. Ma volatile non risolve il problema dell'atomicità , ovvero int a; a++; non è sicuro. COME ci sono tre istruzioni macchina associate ad esso.

Answer 2

Si è corretto, più thread potrebbero tentare di creare un oggetto risorsa. Volatile garantisce solo che se un thread aggiorna il riferimento, tutti gli altri thread vedranno il nuovo riferimento, non un riferimento memorizzato nella cache. Questo è più lento, ma più sicuro.

Se avete bisogno di una sola risorsa che è caricato in modo pigro, è necessario fare qualcosa di simile:

class MyClass 
{ 
     private static volatile Resource resource; 
     private static final Object LOCK = new Object(); 

     public static Resource getInstance() 
     { 
      if(resource == null) { 
       synchronized(LOCK) { // Add a synch block 
        if(resource == null) { // verify some other synch block didn't 
              // write a resource yet... 
         resource = new Resource(); 
        } 
       } 
      } 
      return resource; 
     } 
} 

Answer 3

volatile garanzie di parola chiave che leggono e scrivono a quella variabile sono atomiche.

Secondo la tutorial

Reads and writes are atomic for all variables declared volatile 

Utilizzo di variabili volatili riduce il rischio di coerenza memoria errori, perché ogni scrittura a una variabile volatile, stabilisce una accade-prima relazione con conseguente letture dello stesso variabile. Ciò significa che le modifiche a una variabile volatile sono sempre visibili ad altri thread. Inoltre, significa che quando un thread legge una variabile volatile, non vede solo l'ultima modifica volatile, ma anche gli effetti collaterali del codice che ha portato la modifica a .

Answer 4

credo, si dovrebbe usare syncronized parola chiave prima getInstance definizione.

Per migliorare le prestazioni è possibile utilizzare ricontrollato modello di blocco:

• Double-checked locking and the Singleton pattern on IBM
• Double-checked locking on Wiki

Answer 5

Quando applicato ad un campo, le garanzie volatili Java che:

1. (In tutte le versioni di Java) C'è un ordine globale sulle letture e scrive su una variabile volatile. Ciò implica che ogni thread che accede a un campo volatile leggerà il suo valore corrente prima di continuare anziché (potenzialmente) utilizzando un valore memorizzato nella cache. (Tuttavia, non c'è alcuna garanzia sull'ordinamento relativo delle letture volatili e scrive con letture e scritture regolari, il che significa che è in genere non un utile costrutto di threading.)

2. (In Java 5 o successivo) Volatile legge e scrive stabilire un rapporto accade-prima, proprio come l'acquisizione e rilasciando un mutex .

Più info.

Answer 6

Sei corretto, in questo caso la risorsa può essere costruita due volte a causa della gara che descrivi. Se si desidera implementare un singleton (senza blocco esplicito) in Java 5+, utilizzare un enum singleton come descritto nelle risposte a What is an efficient way to implement a singleton pattern in Java?.

Answer 7

So che non stai chiedendo soluzioni migliori, ma questo è sicuramente la pena se stai cercando una soluzione pigro singleton.

Utilizzare una classe statica privata per caricare il singleton. La classe non viene caricata fino al richiamo e quindi il riferimento non viene caricato fino alla classe. Il caricamento delle classi per implementazione è thread-safe e si verificano anche pochissime spese generali (nel caso si stiano facendo carichi volatili ripetitivi [che possono essere ancora a buon mercato], questa risoluzione carichi sempre normali dopo la costruzione iniziale).

class MyClass { 
    public static Resource getInstance() { 
     return ResourceLoader.RESOURCE; 
    } 

    private static final class ResourceLoader { 
     private static final Resource RESOURCE = new Resource(); 
    } 
} 

Answer 8

prima di tutto, avere un Singleton in questo modo, si sono essenzialmente la creazione di un oggetto globale che è una cattiva pratica. Suppongo che tu usi invece Enums.

Answer 9

Ecco il mio suggerimento di aggiungere volatile & sincronizzato insieme.

Nota: dobbiamo ancora fare doppio controllo.

public class MySingleton { 
    private static volatile MySingleton instance; 
    private MySingleton() {} 

    synchronized private static void newInstance() { 
     if(instance == null) { 
      instance = new MySingleton(); 
     } 
    } 

    public static MySingleton get() { 
     if(instance == null) { 
      newInstance(); 
     } 
     return instance; 
    } 
}