El ejemplo del código que puede probar que declara "volátil" debe usarse

Question

Actualmente no puedo entender cuándo debemos usar volatile para declarar la variable.

Realicé un estudio y busqué algunos materiales al respecto durante mucho tiempo y sé que cuando un campo se declara volátil, el compilador y el tiempo de ejecución reciben aviso de que esta variable se comparte y que las operaciones en ella no deben ser reordenado con otras operaciones de memoria.

Sin embargo, todavía no puedo entender en qué situación deberíamos usarlo. Quiero decir, ¿puede alguien proporcionar algún código de ejemplo que pueda demostrar que usar "volátil" trae beneficios o resolver problemas en comparación con sin usarlo?

Answer 1

Aquí hay un ejemplo de por qué volatile es necesario. Si elimina la palabra clave volatile, el hilo 1 puede nunca terminar. (Cuando probé en Java 1.6 Hotspot en Linux, este fue el caso - los resultados pueden variar a medida que la JVM no está obligado a hacer ningún almacenamiento en caché de variables que no estén marcadas volatile.)

public class ThreadTest { 
    volatile boolean running = true; 

    public void test() { 
    new Thread(new Runnable() { 
     public void run() { 
     int counter = 0; 
     while (running) { 
      counter++; 
     } 
     System.out.println("Thread 1 finished. Counted up to " + counter); 
     } 
    }).start(); 
    new Thread(new Runnable() { 
     public void run() { 
     // Sleep for a bit so that thread 1 has a chance to start 
     try { 
      Thread.sleep(100); 
     } catch (InterruptedException ignored) { } 
     System.out.println("Thread 2 finishing"); 
     running = false; 
     } 
    }).start(); 
    } 

    public static void main(String[] args) { 
    new ThreadTest().test(); 
    } 
} 

Answer 2

La palabra clave volátil es bastante compleja y debe comprender lo que hace y lo que no funciona bien antes de usarla. Recomiendo leer this language specification section que lo explica muy bien.

Destacan este ejemplo:

class Test { 
    static volatile int i = 0, j = 0; 
    static void one() { i++; j++; } 
    static void two() { 
     System.out.println("i=" + i + " j=" + j); 
    } 
} 

Lo que esto significa es que durante one()j nunca es mayor que i. Sin embargo, otro subproceso que ejecuta two() puede imprimir un valor de j que es mucho mayor que i porque digamos que two() se está ejecutando y obtiene el valor de i. Luego one() se ejecuta 1000 veces. Luego, el hilo que ejecuta dos finalmente se programa de nuevo y recoge j que ahora es mucho más grande que el valor de i. Creo que este ejemplo demuestra perfectamente la diferencia entre volátil y sincronizado: las actualizaciones a i y j son volátiles, lo que significa que el orden en que ocurren es consistente con el código fuente. Sin embargo, las dos actualizaciones se producen por separado y no de forma atómica, por lo que las personas que llaman pueden ver valores que se ven (para esa persona que llama) como inconsistentes.

En pocas palabras: ¡tenga mucho cuidado con volatile!

Answer 3

Eric, he leído sus comentarios y uno en particular me sorprende

De hecho, puedo entender el uso de volátiles en el concepto nivel. Sin embargo, para la práctica, no se me ocurre el código que tiene la concurrencia problemas sin utilizar volátil

El problema obvio que puede tener son reordenamientos del compilador, por ejemplo, la más famosa de elevación como se ha mencionado por Simon Nickerson. Pero supongamos que no habrá reordenamientos, ese comentario puede ser válido.

Otro problema que resuelve volátil es con variables de 64 bits (largo, doble). Si escribe en una larga o doble, se trata como dos tiendas separadas de 32 bits. Lo que puede suceder con una escritura simultánea es que el alto 32 de un hilo se escribe en los 32 bits altos del registro, mientras que otro hilo escribe los 32 bits bajos.Entonces puede tener un largo que no sea ni uno ni el otro.

Además, si observa la sección de memoria del JLS, observará que se trata de un modelo de memoria relajado.

Eso significa que las escrituras pueden no ser visibles (pueden estar en el búfer de la tienda) por un tiempo. Esto puede llevar a lecturas obsoletas. Ahora puede decir que parece poco probable, y lo es, pero su programa es incorrecto y tiene el potencial de fallar.

Si tiene un int que está incrementando durante la vida útil de una aplicación y sabe (o al menos piensa) que el desbordamiento de la información no se ampliará, no podrá actualizarlo a una extensión larga, pero aún es posible. . En el caso de un problema de visibilidad de la memoria, si cree que no debería afectarlo, debe saber que todavía puede y puede causar errores en su aplicación simultánea que son extremadamente difíciles de identificar. La corrección es la razón para usar volátil.

Answer 4

El siguiente es un ejemplo canónico de la necesidad de volátil (en este caso para la variable str. Sin ella, hotspot levanta el acceso fuera del bucle (while (str == null)) y run() nunca se termina. Esto ocurrirá en la mayoría de las JVM -server .

public class DelayWrite implements Runnable { 
    private String str; 
    void setStr(String str) {this.str = str;} 

    public void run() { 
      while (str == null); 
      System.out.println(str); 
    } 

    public static void main(String[] args) { 
      DelayWrite delay = new DelayWrite(); 
      new Thread(delay).start(); 
      Thread.sleep(1000); 
      delay.setStr("Hello world!!"); 
    } 
} 

Answer 5

Un ejemplo minimalista en java 8, si se quita la palabra clave volátil que nunca se terminará.

public class VolatileExample { 

    private static volatile boolean BOOL = true; 

    public static void main(String[] args) throws InterruptedException { 
     new Thread(() -> { while (BOOL) { } }).start(); 
     TimeUnit.MILLISECONDS.sleep(500); 
     BOOL = false; 
    } 
}