¿Cuál es la diferencia entre usar una primitiva volátil sobre variables atómicas?

Question

Duplicar posible:
Java: volatile boolean vs AtomicBoolean

cuándo es apropiado utilizar un volatile primitiva (por ejemplo boolean, integer o long) en lugar de AtomicBoolean, AtomicInteger o AtomicLong, y vice-versa?

Answer 1

La semántica de visibilidad es exactamente la misma, la situación en la que es útil utilizar las primitivas atómicas es cuando necesita utilizar sus métodos atómicos.

Por ejemplo:

if (volatileBoolean) { 
    volatileBoolean = !volatileBoolean; 
} 

podría crear problemas en un entorno multihilo como la variable puede cambiar entre las dos líneas. Si necesita la asignación de prueba & ser atómicas, puede utilizar:

atomicBoolean.compareAndSet(true, false); 

Answer 2

usando una volátil llanura es más simple y más eficiente si todo lo que quiere hacer es establecer u obtener el valor. (Pero no obtenga & establezca el valor)

Si desea realizar más operaciones como getAndIncrement o compare Y Swap, debe utilizar las clases AtomicXxxx.

Answer 3

Hemos comenzado a prohibir el uso de volatile en nuestras fuentes porque es muy fácil escribir código que no siempre funciona como se esperaba.

En mi experiencia, las personas agregan volátiles para compartir un valor entre subprocesos. Y luego, alguien más comienza a modificar el valor. Y la mayor parte del tiempo, esto funciona. Pero en producción, comienzas a obtener errores extraños que son realmente difíciles de rastrear. Los contadores se incrementan 100'000 veces (las pruebas solo los incrementan 10 veces) pero terminan en 99'997. En Java 1.4, los valores largos podrían corromperse realmente, muy raramente.

Las clases de ayuda Atomic*, por otro lado, imponen solo una pequeña sobrecarga y siempre funcionan como se anuncia.

De modo que a menos que tenga una muy buena razón (*) para usar volatile, siempre prefiera las clases de ayuda Atomic*.

Si no sabe exactamente lo que hace cada carácter en las clases de ayuda Atomic*, entonces realmente debe evitar volatile.

*: La optimización prematura nunca es una buena razón.

Answer 4

Las clases Atomic* envuelven una primitiva del mismo tipo volatile. Desde la fuente:

public class AtomicLong extends Number implements java.io.Serializable { 
    ... 
    private volatile long value; 
    ... 
    public final long get() { 
     return value; 
    } 
    ... 
    public final void set(long newValue) { 
     value = newValue; 
    } 

So.

Cuándo es apropiado utilizar una primitiva volátil (p.booleano, entero o larga) en lugar de AtomicBoolean, AtomicInteger o AtomicLong

Si todo lo que está haciendo es obtener y establecer un Atomic* entonces puede ser que también acaba de tener un campo volatile lugar.

... y viceversa?

Lo que los Atomic* clases se dan sin embargo, son métodos que proporcionan una funcionalidad más avanzada, como incrementAndGet(), compareAndSet(), y otros que implementan múltiples operaciones (obtener/incremento/set, prueba/set) sin bloqueo. Es por eso que las clases Atomic* son tan poderosas.

También es importante tener en cuenta que envolver su campo volatile utilizando la clase Atomic* es una buena manera de encapsular el recurso compartido crítico desde el punto de vista de un objeto. Esto significa que los desarrolladores no pueden lidiar con el campo suponiendo que no se comparte, posiblemente inyectando problemas con un field++; u otro código que introduce condiciones de carrera.