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

[TimurZhoraev]

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

[Xbolt]

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

[Snaret]

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

[matrixnorm]

быстрее всего работает StringConcatFactoryBuilderManagerProxyServiceExecutorSingletonAdaptor

[Snaret]

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

[vvbob]

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

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

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

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

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