В 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 ответа:
это экстремальная оптимизация Дуг Леа, автор класса, любит использовать. Вот сообщение на недавней теме в списке рассылки core-libs-dev об этой точной теме, которая довольно хорошо отвечает на ваш вопрос.
от модератора:
...копирование в локальные производит наименьший байт-код, а для низкоуровневого кода приятно писать код это немного ближе к машине
этой теме дает ответы на некоторые вопросы. По существу:
- компилятор не может легко доказать, что конечное поле не изменяется внутри метода (из-за отражения / сериализации и т. д.)
- большинство текущих компиляторов на самом деле не пытаются и поэтому должны были бы перезагружать последнее поле каждый раз, когда оно используется, что может привести к пропуску кэша или ошибке страницы
- сохранение его в локальной переменной заставляет JVM выполнять только один загрузить