AtomicReference vs AtomicReferenceFieldUpdater, lo que es un objetivo de AtomicReferenceFieldUpdater?

Netherwire:

Me gustaría mejorar mi referencia atómicamente. Por ejemplo, para su uso compareAndSet, getAndSety otras operaciones atómicas.

Vine de C ++, por lo que en C ++ Tengo volatilepalabra clave y diferentes características intrínsecas atómicas, o la <atomic> API . En Java, también hay una volatilepalabra clave y diferentes operaciones atómicas inseguras .

Por cierto, también hay una bien documentada AtomicReference (así como Long, Integer, Boolean), por lo JDK creadores nos ha proporcionado una manera de ejecutar con seguridad las operaciones atómicas contra referencias y primitivas. No hay nada malo acerca de la API, que es rico y parece muy familiar.

Sin embargo, también hay un AtomicReferenceFieldUpdater whick proporciona una manera un poco raro para ejecutar operaciones atómicas: hay que "encontrar" el campo a través de la reflexión por su nombre y entonces se puede usar exactamente las mismas operaciones.

Así que mis preguntas son:

1. ¿Cuál es la finalidad de AtomicReferenceFieldUpdatertodo? En mi opinión, es implícito y un poco extraño: tiene que declarar una variable volátil presentada Y y el campo de actualización en sí. Entonces, ¿dónde debería usar una FieldUpdater?
2. Proporciona una vía indirecta: usted está manipulando (no cambiar !) El FieldUpdater, no la variable, esto confunde.
3. Rendimiento: por lo que yo sé, tanto AtomicReferenceFieldUpdatery AtomicReferenceestán delegando en el inseguro, por lo que su rendimiento es similar, pero de todos modos: ¿existen penalizaciones en el rendimiento de FieldUpdaterAgaist de referencia?

Xingbin:

Se utiliza para ahorrar memoria.

Ejemplo de la doc:

class Node {
   private volatile Node left, right;

   private static final AtomicReferenceFieldUpdater<Node, Node> leftUpdater =
     AtomicReferenceFieldUpdater.newUpdater(Node.class, Node.class, "left");
   private static AtomicReferenceFieldUpdater<Node, Node> rightUpdater =
     AtomicReferenceFieldUpdater.newUpdater(Node.class, Node.class, "right");

   Node getLeft() { return left; }
   boolean compareAndSetLeft(Node expect, Node update) {
     return leftUpdater.compareAndSet(this, expect, update);
   }
   // ... and so on
 }

declara lefty rightcomo Nodedirectamente. Y el AtomicReferenceFieldUpdateres static final.

Sin AtomicReferenceFieldUpdater, puede que deba declarar como AtomicReference<Node>.

private  AtomicReference<Node> left, right;

que consume más memoria queNode . Cuando hay muchos casos de Node, consume mucha más memoria que la primera aproximación.