¿Cómo puedo usar correctamente la palabra clave volátil en Java?

Question

Supongamos que tengo dos hilos y un objeto. Un hilo asigna el objeto:

public void assign(MyObject o) { 
    myObject = o; 
} 

Otro hilo utiliza el objeto:

public void use() { 
    myObject.use(); 
} 

¿La variable myObject deben ser declarados tan volátil? Estoy tratando de entender cuándo usar volátiles y cuándo no, y esto me desconcierta. ¿Es posible que el segundo hilo mantenga una referencia a un objeto viejo en su memoria caché local? ¿Si no, porque no?

Muchas gracias.

Answer 1

Dejando a los complicados detalles técnicos detrás, se puede ver volatile más o menos como un modificador de synchronizedvariables de. Cuando desea sincronizar el acceso a los métodos o bloques, entonces por lo general le gustaría utilizar el modificador synchronized de la siguiente manera:

public synchronized void doSomething() {} 

Si desea "sincronizar" el acceso a las variables, entonces' d gustaría usar el volatile modificador:

private volatile SomeObject variable; 

Detrás de las escenas que hacen cosas diferentes, pero la efecto es el mismo: los cambios son inmediatamente visibles para el próximo hilo que accede.

En su caso específico, no creo que el modificador volatile tenga algún valor. El volatile no garantiza de ninguna manera que el hilo que asigna el objeto se ejecutará antes de el hilo que utiliza el objeto. Puede ser tan bueno al revés. Probablemente solo quiera hacer una comprobación nula en el método use() primero.

actualización: ver también this article:

El acceso a las variables actúa como si que está encerrado en un bloque sincronizado, sincronizado sobre sí mismo. Decimos "actúa como si" en el segundo punto, porque para el programador al menos (y probablemente en la mayoría de las implementaciones de JVM) no existe un objeto de bloqueo real implicado.

Answer 2

Estoy tratando de comprender cuándo utilizar volátil y cuando no

Debe sobre todo evitar su uso. Use una clase AtomicReference en su lugar (u otra atomic cuando corresponda). Los efectos de memoria son los mismos y la intención es mucho más clara.

Recomiendo leer el excelente Java Concurrency in Practice para una mejor comprensión.

Answer 3

Puede usar volátil en este caso.Necesitará una sincronización volátil alrededor del acceso a la variable o algún mecanismo similar (como AtomicReference) para garantizar que los cambios realizados en el hilo de asignación sean realmente visibles para el hilo de lectura.

Answer 4

Hay algunos comentarios confusos aquí: Para aclarar, el código es incorrecto tal como está, suponiendo que dos hilos diferentes llaman assign() y use().

En ausencia de volatile, u otro sucede-antes de relación (por ejemplo, la sincronización en un bloqueo común) cualquier escribir a myObject en assign() no está garantizado para ser visto por el subproceso de llamada use() - no inmediatamente, no en de manera oportuna, y de hecho nunca.

Sí, volatile es una forma de corregir esto (suponiendo que esto sea un comportamiento incorrecto - ¡hay situaciones plausibles en las que no le importa esto!).

Tiene razón en que el subproceso 'usar' puede ver cualquier valor 'caché' de myObject, incluido el que se le asignó en el momento de la construcción y cualquier valor intermedio (nuevamente en ausencia de otros puntos anteriores).

Answer 5

Declarar una variable volátil de Java significa:

• El valor de esta variable no se almacenan en caché hilo localmente
• Acceso a variable actúa como si estuviera encerrado en un bloque sincronizado

El uso típico y más común de volátil es:

public class StoppableThread extends Thread { 
    private volatile boolean stop = false; 

    public void run() { 
    while (!stop) { 
     // do work 
    } 
    } 

    public void stopWork() { 
    stop = true; 
    } 
} 

Answer 6

He pasado bastante tiempo intentando comprender la palabra clave volatile. Creo que @aleroot ha dado el mejor y más simple ejemplo en el mundo.

Esto es a su vez mi explicación para los simulado (como yo :-)):

Escenario 1: Suponiendo que el stop no se ha declarado tan volátil continuación un hilo dado hace y 'piensa' lo siguiente:

1. stopWork() se llama: tengo que establecer el stop a true
2. Grande, lo hice en mi pila local, ahora tengo que actualizar el montón principal de la JVM.
3. Vaya, JVM me dice que den un paso en la CPU a otro hilo, tengo que parar por un tiempo ...
4. OK, estoy de vuelta. Ahora puedo actualizar el montón principal con mi valor. Actualizando ...

Scenario2: Ahora vamos a la stop declararse tan volátil:

1. stopWork() se llama: Tengo que establecer el stop a true
2. Grande, lo hice en mi pila locales ahora Tengo que actualizar el montón principal de JVM.
3. Lo siento muchachos, tengo que hacer (2) AHORA - Me dicen que es volatile. Tengo que ocupar la CPU un poco más ...
4. Actualizando el montón principal ...
5. Bien, he terminado. Ahora puedo ceder.

Sin sincronización, sólo una idea simple ...

Por qué no declarar todas las variables volatile por si acaso? Debido a Scenario2/Step3. Es un poco ineficiente pero aún mejor que la sincronización regular.