В ArrayBlockingQueue зачем копировать конечное поле участника в локальную конечную переменную?

В 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;
}

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

Ответы

Ответ 1

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

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

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

Ответ 2

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

• компилятор не может легко доказать, что конечное поле не изменяется в рамках метода (из-за отражения/сериализации и т.д.).
• большинство современных компиляторов на самом деле не пытаются и поэтому должны перезагружать конечное поле каждый раз, когда оно используется, что может привести к промаху в кеше или ошибке страницы.
• сохранение его в локальной переменной заставляет JVM выполнять только одну загрузку