Il thread di lettura delle variabili Java ArrayList/String/atomic è sicuro?

Question

Sto rimuginando su questa lettura & ma riesco a trovare una risposta assoluta autorevole.

Ho diverse strutture di dati profonde composte da oggetti contenenti liste di array, stringhe & valori primitivi. Posso garantire che i dati in queste strutture non cambieranno (nessun thread apporterà mai modifiche strutturali alle liste, cambi riferimenti, cambi primitive).

Mi chiedo se la lettura dei dati in queste strutture sia thread-safe; cioè è sicuro leggere le variabili in modo ricorsivo dagli oggetti, iterare le liste di array ecc. per estrarre informazioni dalle strutture in più thread senza sincronizzazione?

Answer 1

L'unico motivo per cui non sarebbe sicuro è se un thread stava scrivendo su un campo mentre un altro thread leggeva simultaneamente da esso. No race condition esiste se i dati non cambiano. Rendere immutabili gli oggetti è un modo per garantire che siano sicuri. Inizia leggendo l'articolo this da IBM.

Answer 2

Proprio come un addendum alle risposte di tutti gli altri: se sei sicuro di dover sincronizzare gli elenchi di array, puoi chiamare Collections.synchronizedList (myList) che ti restituirà un'implementazione thread-safe.

Answer 3

Non riesco a vedere come leggere da ArrayLists, stringhe e valori primitivi che utilizzano più thread dovrebbe essere un problema.

Finché state leggendo, non è necessaria alcuna sincronizzazione. Per le stringhe e i primitivi è sicuramente sicuro poiché sono immutabili. Per ArrayList dovrebbe essere sicuro, ma io non ne ho l'autorizzazione.

Answer 4

fare NON uso java.util.Vector, utilizzare java.util.Collections.unmodifiableXXX() involucro se veramente sono immodificabile, questo garantisce che non cambierà, e far rispettare tale contratto. Se stanno per essere modificati, quindi utilizzare java.util.Collections.syncronizedXXX(). Ma questo garantisce solo la sicurezza del filo interno. Rendere le variabili final aiuterà anche il compilatore/JIT con le ottimizzazioni.

Answer 5

Se i dati non vengono mai modificati dopo la sua creazione, allora si dovrebbe andare bene e le letture saranno thread-safe.

Per sicurezza, è possibile rendere "definitivi" tutti i dati membri e rendere tutte le funzioni di accesso rientranti ove possibile; questo garantisce la sicurezza dei thread e può aiutare a mantenere sicuro il thread del codice se lo cambi in futuro.

In generale, fare in modo che il maggior numero possibile di membri "finali" contribuisca a ridurre l'introduzione di bug, quindi molte persone lo considerano una best practice di Java.

Answer 6

I membri di un ArrayList non sono protetti da alcuna barriera di memoria, quindi non è garantito che le modifiche siano visibili tra i thread. Questo si applica anche quando l'unico "cambiamento" che viene mai fatto alla lista è la sua costruzione.

Qualsiasi dati condivisi tra thread richiede una "barriera di memoria" per garantirne la visibilità. Ci sono diversi modi per farlo.

In primo luogo, qualsiasi membro dichiarato final e inizializzato in un costruttore è visibile a qualsiasi thread dopo il completamento del costruttore.

Le modifiche a qualsiasi membro dichiarato volatile sono visibili a tutti i thread. In effetti, la scrittura viene "svuotata" da qualsiasi cache alla memoria principale, dove può essere vista da qualsiasi thread che accede alla memoria principale.

Ora diventa un po 'più complicato. Qualsiasi scrittura effettuata da un thread prima dello che le scritture di thread su una variabile volatile vengono svuotate. Allo stesso modo, quando un thread legge una variabile volatile, la sua cache viene cancellata e le letture successive possono ripopolarlo dalla memoria principale.

Infine, un blocco synchronized è come una lettura volatile e in scrittura, con la qualità aggiunta di atomicità. Quando il monitor viene acquisito, la cache di lettura del thread viene cancellata. Quando il monitor viene rilasciato, tutte le scritture vengono scaricate nella memoria principale.

Un modo per fare questo lavoro è di avere il filo che riempie la struttura dei dati condivisi assegnare il risultato a una variabile volatile (o un AtomicReference, o altro oggetto adatto java.util.concurrent). Quando altri thread accedono a tale variabile, non solo sono garantiti per ottenere il valore più recente per quella variabile, ma anche eventuali modifiche apportate alla struttura dati dal thread prima che esso assegni il valore alla variabile.