Java referencia volátil vs AtomicReference

Question

¿Hay alguna diferencia entre una referencia de objeto y volatileAtomicReference en caso de que me acaba de utilizar get() y set() -Métodos de AtomicReference?

Answer 1

respuesta corta es: No.

Desde el java.util.concurrent.atomic package doc:

Los efectos de memoria para accesos y actualizaciones de las atómicas generalmente siguen las reglas de volátiles:

• get tiene la memoria efectos de leer una variable volatile.
• set tiene los efectos de memoria de escribir (asignar) una variable volatile.

Por cierto, el doc para el paquete es muy bueno y todo se explica ...

---

lazySet (introducido en Java 6) es una operación más reciente introducido que tiene una semántica inalcanzables a través de volatile variables; ver this post para más información.

Answer 2

No, no lo hay.

La potencia adicional proporcionada por AtomicReference es el método compareAndSet() y sus amigos. Si no necesita esos métodos, una referencia volátil proporciona la misma semántica que AtomicReference.set() y .get().

Answer 3

AtomicReference proporciona funcionalidad adicional que una variable volátil no proporciona. Como ha leído la API, sabrá esto, pero también proporciona un bloqueo que puede ser útil para algunas operaciones.

Sin embargo, a menos que necesite esta funcionalidad adicional, le sugiero que utilice un campo simple volátil.

Answer 4

JDK source code es una de las mejores formas de responder a confusiones como esta. Si observa el código en AtomicReference, usa una variable volátil para el almacenamiento de objetos.

private volatile V value; 

Así que, obviamente, si se va a utilizar sólo get() y set() en AtomicReference es como usar una variable volátil. Pero como comentaron otros lectores, AtomicReference proporciona semántica de CAS adicional. Entonces, primero decida si quiere semántica de CAS o no, y si solo usa AtomicReference.

Answer 5

hay varias diferencias y compensaciones:

1. Usando un AtomicReference get/set tiene el mismo semántica JMM como un campo volátiles (como los estados javadoc), pero el AtomicReference es una envoltura alrededor de una referencia, por lo que cualquier acceso al campo implica una persecución de puntero adicional.

2. La huella memoria se multiplica (asumiendo un entorno OOPs comprimido, lo cual es cierto para la mayoría de las máquinas virtuales):

   • ref volátil = 4b
   • AtomicReference = 4b + 16b (cabecera de objeto 12b + Campo 4b ref)

3. AtomicReference ofrece una API más rica que una referencia volátil. Puede recuperar la API para la referencia volátil utilizando AtomicFieldUpdater, o con Java 9 a VarHandle. También puede comunicarse directamente con sun.misc.Unsafe si le gusta correr con unas tijeras. AtomicReference en sí se implementa utilizando Unsafe.

lo tanto, cuando es bueno elegir una sobre la otra:

• sólo necesitan obtener/poner? Quédese con un campo volátil, la solución más simple y la menor sobrecarga.
• ¿Necesita la funcionalidad adicional? Si se trata de una parte sensible del rendimiento (velocidad/sobrecarga de memoria) de su código, haga una elección entre AtomicReference/AtomicFieldUpdater/Unsafe donde tiende a pagar en legibilidad y riesgo para su ganancia de rendimiento. Si esto no es un área sensible, solo haga clic en AtomicReference. Los escritores de bibliotecas suelen utilizar una combinación de estos métodos según los JDK específicos, las restricciones esperadas de la API, las limitaciones de memoria, etc.