И снова здрасьте! Мы открыли очередной набор в, теперь уже девятую, группу «Разработчик Java» (а десятая группа в планах, внезапно, стоит на 31.12) и подготовили для вас интересные материалы и открытый урок.
Так что поехали.
Хотите уменьшить количество памяти используемой вашим Java-приложением? Посмотрите, как можно улучшить производительность с помощью компактных строк, доступных в Java 9.
Одним из решений по улучшению производительности, представленных в JVM (Oracle HotSpot, если быть точным), в качестве части Java SE 9, оказались компактные строки (compact strings). Их задача заключается в уменьшении размера String-объектов, что позволяет уменьшить общий объем (футпринт) памяти потребляемой приложением. В результате, это может уменьшить количество времени, затрачиваемого на сбор мусора.
В основе функции лежит наблюдение, что многим String-объектам не требуется 2 байта для кодирования каждого символа, так как большинство приложений использует только символы Latin-1. Следовательно, вместо такого:
/** это значение используется для хранения символа */
private final char value[];
В java.lang.String теперь есть это:
private final byte[] value;
/**
* идентификатор кодировки используется для кодирования байтов в
* {@code value}. В этой имплементации поддерживаются следующие значения:
*
* LATIN1
* UTF16
*
* @implNote Виртуальная машина доверяет этому полю. Оно подлежит постоянному
* “сворачиванию”, если инстанс String - константа. Перезапись этого
* поля после конструирования может вызвать проблемы.
*/
private final byte coder;
Другими словами, эта функция заменяет значение в массиве char (где каждый элемент использует 2 байта) байтовым массивом с дополнительным байтом для определения кодировки (Latin-1 или UTF-16). Это значит, что в большинстве приложений, использующих только символы Latin-1, будет применяться лишь половина кучи. Пользователь не заметит отличий, но связанные API, например, StringBuilder, автоматически этим воспользуются.
Чтобы показаться это изменение с точки зрения размера String-объекта, я воспользуюсь Java Object Layout — простой утилитой для визуализации структуры объекта в куче. С этой точки зрения, нас интересует футпринт массива (хранящегося в переменной value выше), а не просто ссылка (ссылка байтового массива, как и ссылка массива символов, использует 4 байта). Код ниже выводит информацию при помощи JOL GraphLayout:
public class JOLSample {
public static void main(String[] args) {
System.out.println(GraphLayout.parseInstance("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz").toFootprint());
}
}Запуск кода выше в Java 8, а затем в Java 9 показывает разницу:
$java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
$java -cp libjol-cli-0.9-full.jar;. test.JOLSample
java.lang.String@4554617cd footprint:
COUNT AVG SUM DESCRIPTION
1 432 432 [C
1 24 24 java.lang.String
2 456 (total)
...
$java -version
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
$java -cp libjol-cli-0.9-full.jar;. test.JOLSample
java.lang.String@73035e27d footprint:
COUNT AVG SUM DESCRIPTION
1 224 224 [B
1 24 24 java.lang.String
2 248 (total)
Игнорируя 24-байтный размер внутренних составляющих java.lang.String (заголовок плюс ссылки), мы видим, что благодаря компактности размер уменьшился почти в два раза.
Если мы заменим строку выше на другую, использующую символы UTF-16, например u0780, а затем перезапустим код выше, то и Java 8, и Java 9 покажут одинаковый футпринт, так как компактность больше не будет использоваться.
Эту функцию можно отключить, передав параметр -XX:-CompactStrings команде java.
Как всегда ждём ваши комментарии и вопросы тут, а так же приглашаем на открытый урок.
Автор: MaxRokatansky
