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

En ArrayBlockingQueue, todos los métodos que requieren el bloqueo lo copian en una finalvariable local antes de llamar 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.locka una variable local lockcuando el campo this.lockes final?

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

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

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

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.

del post:

... copiar a locales produce el código de bytes 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

Este hilo da algunas respuestas. En sustancia:

• el compilador no puede probar fácilmente que un campo final no cambia dentro de un método (debido a la 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 provocar una falla de caché o una falla de página
• almacenarlo en una variable local obliga a la JVM a realizar solo una carga