In ArrayBlockingQueue, why copy final member field into local final variable?

В ArrayBlockingQueue все методы, требующие блокировки, копируют его в локальную final переменную перед вызовом 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();
    }
}

Есть ли какая-либо причина копировать this.lock в локальную переменную lock , когда поле this.lock является final?

Кроме того, он также использует локальную копию E[], прежде чем действовать с ней:

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

Есть ли какая-либо причина для копирования поля final в локальную конечную переменную?

Это экстремальная оптимизация, которую любит использовать Дуг Ли, автор класса. Вот сообщение в недавнем потоке в списке рассылки core-libs-dev именно на эту тему, которое довольно хорошо отвечает на ваш вопрос.

из сообщения:

... копирование в locals создает наименьший байт-код, а для низкоуровневого кода приятно писать код, который немного ближе к машине

Этот поток дает некоторые ответы. По сути:

• компилятор не может легко доказать, что конечное поле не изменяется внутри метода (из-за отражения / сериализации и т.д.)


• большинство современных компиляторов на самом деле не пытаются, и поэтому им придется перезагружать final field каждый раз, когда оно используется, что может привести к пропуску кэша или ошибке страницы


• сохранение его в локальной переменной вынуждает JVM выполнять только одну загрузку