Всем привет.
Эта статья — вольный перевод поста StringBuffer, and how hard it is to get rid of legacy code. Как-то очень он мне запал в душу, поэтому решил перевести. Поехали.
В 2006-м, в 5-й java появился StringBuilder. Более легковесная и разумная альтернатива StringBuffer. Вот, что говорит официальная документация по StringBuffer:
Этот класс дополнен аналогичным классом предназначенным для использования в одном потоке — StringBuilder. В общем случае нужно отдавать предпочтение классу StringBuilder, так как он поддерживает все те же операции, что и этот (StringBuffer), но быстрее, так как не выполняет никаких синхронизаций.
Иметь synchronized в StringBuffer вообще никогда не было хорошей идеей. Основная проблема в том, что одной операции никогда не достаточно. Одиночная конкатенация .append(x) бесполезная без других операций, таких как .append(y) и .toString(). В то время, когда каждый конкретный метод потокобезопасный, вы не можете сделать несколько вызовов без конкуренции между потоками. Ваша единственная опция — внешняя синхронизация.
Так, что? Получается, 10 лет спустя уже никто не использует StringBuffer!? Ну, по крайней мере, точно не для нового функционала!?
Сколько объектов создает этот код?
Как я уже писал раньше, виртуальная машина создает много объектов на старте или при загрузке основных библиотек. Гораздо больше, чем Вы могли бы представить, задавая вопрос выше:
public class Main {
public static void main(String... args) {
System.out.println("Hello " + "world");
}
}
Oracle JVM 8-й версии создает приблизительно 10_000 объектов для выполнения этой программы.
Сколько же это создается StringBuffers?
Итак, чтобы запустить JVM нужно создать много объектов, но старые классы, у которых есть более быстрая альтернатива, которой уже 10 лет не должны быть использованы, так ведь?
public class Main {
public static void main(String[] args) throws IOException {
System.out.println("Waiting");
System.in.read();
}
}Пока процесс запущен, мы можем выполнить следующую команду:
jmap -histo {pid} | grep StringBuffer
и получаем:
18: 129 3096 java.lang.StringBuffer
129 это количество объектов StringBuffer которые создала Java 8 Update 121. Это меньше, чем в прошлый раз, когда я проверял, но всё равно, немножко удивительно.
(Проверил у себя на Java 8 update 131, получил всего 14 объектов).
А как на счет новых фич — лямбд и стримов? Они были созданы явно в последние 10 лет и используют некоторые сторонние библиотеки, вроде Objectwebs ASM. И эти разработчики точно знают внутренности виртуальной машины и должны были спроектировать новые фичи максимально легковесными.
public class Main {
public static void main(String[] args) throws IOException {
IntStream.range(0, 4).forEach(System.out::println);
System.out.println("Waiting");
System.in.read();
}
}Запускаем jmap опять и что мы видим?
17: 545 13080 java.lang.StringBuffer
Дополнительные 416 объектов для простейшей лямбды и стрима!
(Опять проверил у себя на Java 8 update 131 и получил 430 объектов, то есть разница в те же 416 объектов. Похоже, что стримы и лямбды не подчистили).
Кстати, программа выше в целом создает:
Total 35486 4027224
или 35_486 объектов!
Выводы
Конечно же, использование StringBuffer на старте приложения не делает особой разницы, но зная, что есть годная альтернатива и StringBuffer до сих пор используется даже в новых фичах — показывает, как трудно бывает избавится от наследия старого кода или изменить людей использовать лучшие практики.
P. S.
В оригинальном посте оставили ссылку на тикет очистки от StringBuffer в 9-ке.
Так что вполне возможно через 3 месяца мы останемся без наследия :), правда речь лишь о StringBuffer. Не забываем про Vector, Hashtable и прочие приятности.
Автор: doom369
