Quando è sicuro non sincronizzare le variabili di lettura/scrittura?

Question

In Java, quando è possibile "allontanarsi" se non si utilizzano sincronizzati su variabili che sono in lettura/scrittura per più thread simultanei?

Ho letto di un paio di sorprendenti bug di concorrenza: double-checked-locking e hash-maps e ho sempre utilizzato la sincronizzazione per impostazione predefinita in casi di lettura/scrittura condivisi, tuttavia, ho iniziato a chiedermi quando è OK non farlo.

Per esempio, che tipo di regole generali posso usare per decidere quando è realtà sicuro di omettere synchronized dai metodi come questo:

T getFoo() { 
    if (this.foo == null) { 
    this.foo = createFoo() // createFoo is always thread safe. 
    } 
    return this.foo; 
} 

Dove:

• T potrebbe essere primitivi o oggetti arbitrari
• createFoo è sempre thread-safe e può essere chiamato più volte, ma è altrimenti unsp ecified.
• getFoo() può essere "alla fine coerente".

Va bene se T sono primitive come int? Che mi dici di Integer? Che dire degli oggetti semplici, come String? Etc.

Answer 1

Quando è opportuno non sincronizzare le variabili di lettura/scrittura?

La risposta tongue-in-cheek è Solo quando si comprende appieno le implicazioni per l'hardware sottostante, la JVM, e la vostra applicazione. Se possibile, consiglierei comunque questo approccio, che inizia con molte letture ed esperimenti.

In pratica, dovresti essere in grado di utilizzare alcuni modelli di uso comune per ridurre al minimo la quantità di metodi o blocchi synchronized nel codice, senza comprendere tutte le complessità di detti modelli. Questo non dovrebbe aumentare troppo il rischio per la tua applicazione, perché ci sono dettagli non banali anche intorno all'uso di synchronized e se hai compreso tutti questi dettagli, avresti fatto una domanda diversa.

Ancora, il tuo chilometraggio può variare, specialmente se la forma e l'implementazione di detti modelli comunemente usati non sono benedetti dal tuo guru della concorrenza locale.

blatera Basta, mi dia qualche esempio

1. Uso collezioni thread-safe, utilità e tipi.
   • Questo include fare affidamento su java.util.concurrent ove possibile.
   • C'è anche una quantità enorme di librerie e strumenti aggiuntivi per Java al di fuori del JDK e del suo ecosistema, ma non si qualificano facilmente per "applica ora, leggi più tardi".
2. Utilizzando volatile
   • Si può dare un'occhiata al http://www.ibm.com/developerworks/library/j-jtp06197/ per alcuni modelli comuni che utilizzano volatile variabili.
3. Utilizzando l'inizializzazione sicura e la pubblicazione sicura
   • È possibile dare un'occhiata a http://shipilev.net/blog/2014/safe-public-construction/ per quello che può essere una spiegazione un po 'più avanzato rispetto è appropriato per un principiante.
   • Vorrei anche inserire tipi immutabili qui.
4. Mantenere i dati locali.
   • Tipo di un non-sforzo, e sorprendentemente spesso applicabile.

Answer 2

Non è mai sicuro condividere dati tra thread senza una barriera di memoria.

La correttezza di getFoo() dipende dalla dichiarazione del campo foo.

Se getFoo() viene chiamato da più thread, ogni thread potrebbe terminare con un'istanza diversa di T. Senza una barriera di memoria, le azioni di un thread (come l'assegnazione al campo foo) potrebbero non essere mai visibili ad altri thread, mai! In altre parole, senza sincronizzazione, coerenza, "eventuale" o altro, non è garantito.

Se foo è volatile, che funge da barriera di memoria sufficiente, e poi basta solo avere il problema che più thread potrebbero ottenere una diversa T per un breve periodo di tempo nella loro corsa per creare istanze.