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

Недавно я столкнулся с классом, в котором было объявлено следующее поле:

private final int period = 1000;

В этом конкретном случае автор намеревался сделать его также статическим, и, поскольку значение нельзя было изменить в любой момент, не было реальной функциональной причины не объявлять его статическим, но это заставило меня задуматься, как Java обрабатывает final vs. окончательные статические примитивы.

Особенно:

1) Как хранятся окончательные статические примитивы? Они просто скомпилированы непосредственно в выражения, в которых они используются?

2) Если они фактически выделены для хранения, должен ли каждый экземпляр содержащего класса поддерживать ссылку на это место? (в этом случае для примитивов размером менее 4 байт каждый экземпляр класса на самом деле будет больше, чем если бы он просто включал примитив напрямую, как это было бы в нестатическом случае)

3) Достаточно ли теперь компиляторы сообразительны, чтобы определить, что в случаях, подобных приведенному выше, переменная является «фактически статической», поскольку было бы невозможно, чтобы разные экземпляры содержали разные значения и, следовательно, оптимизировали ее аналогично окончательному статическому?


java final private static
person Dusty    schedule 30.09.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

1) Как хранятся окончательные статические примитивы? Они просто скомпилированы непосредственно в выражения, в которых они используются?

Не компилируется непосредственно в выражения. Они компилируются в файл .class, и на них ссылается код операции ldc.

2) Если они фактически выделены для хранения, должен ли каждый экземпляр содержащего класса поддерживать ссылку на это место? (в этом случае для примитивов размером менее 4 байт каждый экземпляр класса на самом деле будет больше, чем если бы он просто включал примитив напрямую, как это было бы в нестатическом случае)

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

3) Достаточно ли теперь компиляторы сообразительны, чтобы определить, что в случаях, подобных приведенному выше, переменная является «фактически статической», поскольку было бы невозможно, чтобы разные экземпляры содержали разные значения и, следовательно, оптимизировали ее аналогично окончательному статическому?

Не уверен, но сомневаюсь, что он оптимизирован на уровне компилятора. JIT, вероятно, вступит в игру. Однако я совсем не уверен, какие «разницы в производительности» вы ожидаете. В любом случае влияние на производительность будет незначительным. (статический/нестатический/окончательный/неокончательный)

person Kirk Woll    schedule 30.09.2010
comment
Re: # 3, я на самом деле не ожидал различий в производительности с точки зрения скорости, но не знал, можно ли оптимизировать, не сохраняя его для каждого экземпляра в соответствии с фактическими статическими конечными полями. Оглядываясь назад, разница в производительности, вероятно, является неправильным. Спасибо за разъяснения - person Dusty; 01.10.2010