В Java там различие в производительности между ссылкой на поле через метод считывания по сравнению с через переменную?

Это ничтожный ущерб. Не беспокойтесь об этом слишком много, иначе вы станете жертвой преждевременной оптимизации. Если ваше приложение работает медленно, причина не в этом.

Разница в том, что доступ к переменным через геттеры приводит к вызову метода. JVM, вероятно, сможет оптимизировать вызов метода при некоторых обстоятельствах, но это является вызовом метода.

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

Нет, если у вас хорошая JVM, например HotSpot от Sun. Он встроит и скомпилирует (в собственный код) геттеры.

Использование геттеров, как правило, является очень хорошей практикой в ​​качестве меры защиты и общего сокрытия информации.

Существует снижение производительности (которое может быть настолько маленьким, что пренебрежимо мало) Тем не менее, JVM может встроить это и все вызовы для улучшения производительности.

Было бы лучше, если бы вы оставь второй способ.

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

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

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

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

Я решаю эту конкретную проблему особым образом для моей JIT. Обратите внимание, что описание здесь является концептуальным, и код реализует его несколько иначе из соображений производительности. Когда я загружаю сборку, я отмечаю в дескрипторе метода, если он просто возвращает поле члена. Позже, когда я JIT использую другие методы, я заменяю все инструкции call для этих методов в байтовом коде инструкцией ldfld перед передачей их генератору собственного кода. Таким образом, я могу:

1. Экономить время в JIT ( ldfld требует меньше процессорного времени для JIT, чем вызов ).
2. Встроенные свойства даже в базовый компилятор .
3. По большому счету гарантия того, что использование шаблона общедоступные свойства / частные поля не повлечет за собой какого-либо снижения производительности при отсоединении отладчика. (Когда прикреплен отладчик, я могу '