sirve - uso del final en java

En ArrayBlockingQueue, ¿por qué copiar el campo miembro final en la variable final local?

Question

En ArrayBlockingQueue , todos los métodos que requieren el bloqueo lo copian a una variable final local antes de llamar a lock() .

public boolean offer(E e) {
if (e == null) throw new NullPointerException();
final ReentrantLock lock = this.lock;
lock.lock();
try {
if (count == items.length)
return false;
else {
insert(e);
return true;
}
} finally {
lock.unlock();
}
}

¿Hay alguna razón para copiar this.lock en un lock variable local cuando el campo this.lock es final ?

Además, también utiliza una copia local de E[] antes de actuar sobre ella:

private E extract() {
final E[] items = this.items;
E x = items[takeIndex];
items[takeIndex] = null;
takeIndex = inc(takeIndex);
--count;
notFull.signal();
return x;
}

¿Hay alguna razón para copiar un campo final a una variable final local?

Answer 1

Es una optimización extrema que le gusta usar a Doug Lea, el autor de la clase. Aquí hay una publicación en un hilo reciente en la lista de correo core-libs-dev sobre este tema exacto que responde bastante bien a su pregunta.

de la publicación:

... copiar a los locales produce el bytecode más pequeño, y para el código de bajo nivel es bueno escribir código que esté un poco más cerca de la máquina

Answer 2

Este hilo da algunas respuestas. En sustancia:

• el compilador no puede demostrar fácilmente que un campo final no cambia dentro de un método (debido a reflexión / serialización, etc.)
• la mayoría de los compiladores actuales en realidad no lo intentan y, por lo tanto, tendrían que volver a cargar el campo final cada vez que se usa, lo que podría ocasionar la falla de una caché o de una página.
• almacenarlo en una variable local fuerza a la JVM a realizar solo una carga