Perché le variabili in Java non sono volatili per impostazione predefinita?

Question

domanda Forse simile:

Do you ever use the volatile keyword in Java?

---

Oggi stavo debug di mio gioco; Aveva un problema di thread molto difficile che si presentava ogni pochi minuti, ma era difficile da riprodurre. Quindi prima ho aggiunto la parola chiave synchronized a ciascuno dei miei metodi. Non ha funzionato. Quindi ho aggiunto la parola chiave volatile a ogni campo. Il problema sembrava risolversi da solo.

Dopo alcuni esperimenti, ho trovato che il campo responsabile era un oggetto GameState che teneva traccia dello stato attuale del mio gioco, che può essere in riproduzione o occupato. Se occupato, il gioco ignora l'input dell'utente. Quello che avevo era un thread che modificava costantemente la variabile state, mentre il thread Event legge la variabile state. Tuttavia, dopo che un thread ha modificato la variabile, sono necessari alcuni secondi affinché l'altro thread riconosca le modifiche, il che causa il problema.

È stato risolto rendendo la variabile di stato volatile.

Perché non sono variabili in Java volatile per impostazione predefinita e quale motivo non utilizzare la parola chiave volatile?

Answer 1

Per farla breve, le variabili volatili, siano esse in Java o C#, non vengono mai memorizzate nella cache localmente all'interno del thread. Questo non ha molte implicazioni a meno che non si abbia a che fare con una CPU multiprocessore/multicore con thread che eseguono su core diversi, poiché guarderebbero la stessa cache. Quando si dichiara una variabile come volatile, tutte le letture e le scritture vengono direttamente e passano direttamente alla posizione di memoria principale effettiva; non ci sono cache coinvolte. Questo ha implicazioni quando si tratta di ottimizzazione, e farlo inutilmente (quando la maggior parte delle variabili non ha bisogno di essere volatili) infliggerebbe una penalizzazione delle prestazioni (insignificante come potrebbe o non potrebbe essere) per un guadagno relativamente piccolo.

Answer 2

Poiché il compilatore non è in grado di ottimizzare le variabili volatili.

volatile indica al compilatore che la variabile può cambiare in qualsiasi momento. Pertanto, non può presumere che la variabile non cambierà e ottimizzerà di conseguenza.

Answer 3

La dichiarazione delle variabili volatili ha generalmente un impatto enorme sulle prestazioni. Sui tradizionali sistemi a thread singolo, era relativamente facile sapere cosa doveva essere volatile; erano quelle cose che accedevano all'hardware.

Su multithreading può essere un po 'più complesso, ma in genere incoraggerei l'utilizzo di notifiche e code di eventi per gestire i dati di passaggio tra i thunders in leau delle variabili magiche. In Java potrebbe non avere molta importanza; in C/C++ si finirebbe nei guai quando quelle variabili non possono essere impostate atomicamente dall'hardware sottostante.

Answer 4

Mentre altri hanno ragione nel sottolineare perché sarebbe una cattiva idea impostarsi su volatile, c'è un altro punto da fare: c'è molto probabilmente un bug nel codice. Le variabili raramente devono essere rese volatili: esiste sempre un modo per sincronizzare correttamente l'accesso alle variabili (tramite parola chiave sincronizzata o usando oggetti AtomicXxx da java.util.concurrency): le eccezioni includono il codice JNI che manipola questi (che non è vincolato da direttive di sincronizzazione).

Quindi, invece di aggiungere volatile, è possibile capire perché ha risolto il problema. Non è l'unico modo per risolverlo, e probabilmente c'è un modo migliore.

Answer 5

volatili siano realmente necessari solo quando si sta cercando di scrivere di basso livello, codice libero-lock thread-safe. La maggior parte del codice, probabilmente non dovrebbe essere sia thread-safe o libera blocco. Nella mia esperienza, la programmazione lock-free vale la pena di tentare solo dopo aver scoperto che la versione più semplice che compie con il blocco si sta verificando un notevole calo di prestazioni a causa del blocco.

L'alternativa più piacevole è quella di utilizzare altri blocchi predefiniti in java.util.concurrent, alcuni dei quali sono senza blocco, ma non si scherza con la testa tanto quanto cercare di fare tutto da soli a un livello basso.

La volatilità ha i suoi costi di prestazione, e non c'è motivo per cui il codice più dovrebbe sostenere tali costi.

Answer 6

Personalmente penso che i campi avrebbero dovuto essere finale per impostazione predefinita e mutabile solo con una parola chiave in più, ma che barca ha navigato lungo tempo fa. ;)