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