StringBuffer, и как тяжело избавиться от наследия старого кода

Всем привет.
Эта статья — вольный перевод поста StringBuffer, and how hard it is to get rid of legacy code ^[1]. Как-то очень он мне запал в душу, поэтому решил перевести. Поехали.

В 2006-м, в 5-й java появился StringBuilder. Более легковесная и разумная альтернатива StringBuffer. Вот, что говорит официальная документация ^[2] по 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 до сих пор используется даже в новых фичах — показывает, как трудно бывает избавится от наследия старого кода или изменить мышление ^[3] людей использовать лучшие практики.

P. S.
В оригинальном посте оставили ссылку ^[4] на тикет очистки от StringBuffer в 9-ке.
Так что вполне возможно через 3 месяца мы останемся без наследия :), правда речь лишь о StringBuffer. Не забываем про Vector, Hashtable и прочие приятности.

Автор: doom369

Источник ^[5]