Используя статические переменные для Строк
ниже содержания взят от Лучшей практики: Написание эффективного кода, но я не понял почему
private static String x = "example";
быстрее, чем
private static final String x ="example";
Может кто-либо объяснять это.
Используя статические переменные для Строк
При определении статических полей (также названный полями класса) Строки типа можно увеличить скорость приложения при помощи статических переменных (не окончательный) вместо констант (финал). Противоположное верно для примитивных типов данных, таково как интервал.
Например, Вы могли бы создать Строковый объект следующим образом:
private static final String x = "example";Для этой статической константы (обозначенный заключительным ключевым словом), создается каждый раз, когда Вы используете константу, временный Строковый экземпляр. Компилятор устраняет "x" и заменяет его строкой "пример" в байт-коде, так, чтобы Виртуальная машина BlackBerry® Java® выполнила поиск хеш-таблицы каждый раз, когда Вы ссылаетесь на "x".
Напротив, для статической переменной (никакое заключительное ключевое слово), Строка создается однажды. BlackBerry JVM выполняет поиск хеш-таблицы только, когда он инициализирует "x", таким образом, доступ быстрее.
private static String x = "example";Можно использовать общедоступные константы (то есть, заключительные поля), но необходимо отметить переменные как частные.
4 ответа
Я не знал об этом, но для меня это имеет смысл:
JVM имеет внутренний кэш строковых литералов. Каждый раз, когда вы создаете String с помощью литерала, JVM должна искать его в кеше, а если его там нет, сохранять.
Теперь компилятор может встроить конечную переменную с строковым литералом, потому что он известен во время компиляции и кажется хорошей идеей для повышения производительности.
Итак, ваш код:
static final String CONST = "myconst";
...
if (CONST.equals(aVar))
...
case CONST
...
переписывается компилятором на:
static final String CONST = "myconst";
...
if ("myconst".equals(aVar))
...
case "myconst"
...
Если реализация JVM недостаточно умна, ей нужно трижды найти myconst в этом примере.
Если вы не помечаете CONST как «final», компилятор не может «оптимизировать» его, поскольку переменная может изменяться во время выполнения. Ваш код будет скомпилирован 1: 1, и JVM нужно будет только искать объект в переменной.
Кстати: плохие реализации JVM не должны определять ваш стиль кодирования. "final" обеспечивает большую безопасность, если он действительно не влияет на вашу производительность: не заботьтесь о том, увеличивает или уменьшает вашу скорость - все равно это другое для следующей JVM
текст объясняет это, просто прочитайте его.
но переформулировать: Это быстрее, потому что это так. То, как сделан blackberry jvm, лучше использовать не финальную версию. Это так, потому что так задумано
.Это особенности виртуальной машины Blackberry. Другая виртуальная машина может сделать это иначе.
Боковое примечание: не уделяйте слишком много внимания оптимизации, пока вы не столкнетесь с проблемами производительности (это называется «преждевременной оптимизацией»), потому что, если вы это сделаете, очень вероятно, что производительность упадет в том месте, где вы никогда не ожидал этого.
Имеется пул строковых литералов среды выполнения. Когда вы создаете Strings как Final, JVM создает копию String каждый раз, когда вы ее используете. Когда строка не является окончательной, она вставляется в пул строковых литералов в первый раз, когда вы ее создаете, а затем после этого она просто просматривается из пула, это позволяет избежать копий строк.