Конкатенация строк в Java: почему советы 2008 года всё ещё работают — и почему этого уже недостаточно

[TimurZhoraev]

Шпаргалка - это прямой путь захардкодить её в виде @ArchTest, public static Collector<CharSequence, ?, String> , @Builder. Скорее нужно иметь некий внешний инструмент которые эти кейсы умеет парсить и идентифицировать bottleneck. То есть не перекладывать проблемы компилятора и анализа проекта на ручной код. Фактически в таблице имеются скрытые численные параметры позволяющие точно идентифицировать что использовать при статике и в динамике, определяя количество строк, их размер и количество конкатенаций

[Xbolt]

Уже java 26, а тут только 24. Хочется большего

[Snaret]

А дальше по это теме пока не особо) StringTemplates и все)

[Xbolt]

Вот только мне не удалось в java 25 их применить, хотя пишут, что там это есть...

[Snaret]

это если его запустить через EscapeAnalysisInvokeDynamicStringTemplatesGarbageCollector

[vvbob]

Стримы в Java - удобный инструмент. Но с конкатенацией строк они сочетаются опасно. Вот типичный код, который я встречал в нескольких проектах:

String result = items.stream().reduce("", (acc, item) -> acc + item)

Выглядит как декларативная агрегация - чисто, функционально, по всем правилам современной Java. Но по факту это классический аккумулятор с повторным копированием строки на каждой итерации. Каждый шаг редукции создаёт новую строку, копируя всё, что было накоплено до этого. На 10 000 элементов - около 50 миллионов операций копирования символов и 10 000 временных строк.

Думаю ,что если вы таким образом склеиваете 10 000 строк, то у вас проблемы не со стринг билдером, а с головой с алгоритмом. Стоит задуматься - а нафига вы такое в принципе делаете, и нельзя ли это сделать как-то по другому, например, если исходные строки берутся из БД, то использовать ее возможности, или потоки операционки или просто вручную создать массив символов требуемого размера и в него все закинуть..

Чаще всего если что-то такое и пишется, то там строк немного склеивается и вся эта борьба с аллокациями становится в этом случае экономией на спичках. Иногда в этом есть смысл ,если нужен прямо суперскоростной код, но это опять-же очень уж нетипичная ситуация.

[Snaret]

Полностью согласен) Но иногда и такое встречается. Поэтому не мог не подсветить)

[rusia2054]

Добрый день, спасибо больше за статью. Вы не сравнивали относительное сравнение потреблении памяти при конкатенации (Plus vs Builder)?

[Snaret]

ПРивет! Спасибо за отзыв)
Сравнение памяти я не включил сознательно. Чтобы его замерить нужен либо профилировщик (VisualVM/YourKit), либо JMH с нативными хуками и это сильно усложнило бы и без того длинную статью.

Вместо памяти я анализировал аллокации и поведение GC (-Xlog:gc=info), потому что именно временные объекты и GC-паузы - главная проблемаа конкатенации в продакшене.