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


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

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

2 66

2 ответа:

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

от модератора:

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

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

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