В ArrayBlockingQueue зачем копировать поле последнего члена в локальную переменную final? - PullRequest
75 голосов
/ 07 мая 2010

В ArrayBlockingQueue все методы, требующие блокировки, перед вызовом lock().

копируют его в локальную переменную final.
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 ]

62 голосов
/ 07 мая 2010

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

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

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

11 голосов
/ 14 марта 2013

Эта тема дает несколько ответов. По содержанию:

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