🔤 Розділ 12 · Питання #8

Як компілятор Java оптимізує конкатенацію рядків

Оптимізація конкатенації рядків у Java — це багаторівневий процес, розподілений між компілятором вихідного коду (javac) та віртуальною машиною HotSpot JVM. Головна мета оптиміза...

🔤 String 📄 Вихідний Markdown

🟢 Junior Level

Оптимізація конкатенації рядків у Java — це багаторівневий процес, розподілений між компілятором вихідного коду (javac) та віртуальною машиною HotSpot JVM. Головна мета оптимізацій — звести до мінімуму виділення пам’яті в купі (Heap), уникнути зайвого копіювання масивів байтів та знизити навантаження на збирач сміття (GC).

Суть у 30 секундах

Компілятор застосовує дві принципові стратегії оптимізації:

  1. На етапі компіляції (Compile-Time) — Згортання констант (Constant Folding): Якщо компілятор бачить зчеплення рядкових літералів або константних змінних (final), він обчислює та об’єднує їх безпосередньо під час збирання коду. У скомпільований .class-файл записується один готовий рядок, а в рантаймі процесор не витрачає на це жодного такту.
  2. Під час виконання (Runtime) — Динамічна генерація коду (JEP 280): Починаючи з Java 9, для динамічних змінних компілятор javac більше не вшиває жорсткий байт-код зі StringBuilder. Натомість генерується інструкція invokedynamic, яка викликає фабрику StringConcatFactory. Фабрика розраховує точний розмір масиву байтів, запобігає проміжним переалокаціям і з’єднує дані на рівні швидких низькорівневих інструкцій.
// 1. Оптимізація javac на етапі компіляції:
public static final String PREFIX = "ORDER_";
String id1 = PREFIX + "123" + "_PENDING"; 
// У байт-код запишеться: ldc "ORDER_123_PENDING" (0 обчислень у рантаймі)

// 2. Оптимізація рантайму для динамічних даних:
String generateKey(String entity, long id) {
    // У байт-код генерується invokedynamic makeConcatWithConstants
    // Примітив long форматується безпосередньо в масив байтів без боксингу в Long!
    return entity + ":" + id;
}

🟡 Middle Level

Еволюція оптимізацій у версіях Java

Стратегія компілятора радикально змінювалася з розвитком платформи:

  • Java 1.0 – 1.4: Вираз a + b компілювався у new StringBuffer().append(a).append(b).toString(). Усі виклики були синхронізованими та повільними.
  • Java 5 – 8: Заміна на new StringBuilder().append(a).append(b).toString(). Синхронізацію було усунуто, але байт-код залишався жорстко прив’язаним до класу StringBuilder з його початковою місткістю за замовчуванням у 16 символів, що спричиняло зайві алокації та розширення внутрішнього буфера для довших рядків.
  • Java 9+ (JEP 280: Indify String Concatenation): Перехід на invokedynamic та StringConcatFactory. Байт-код став компактним, вибір стратегії генерації винесено в рантайм, а виділення пам’яті стало суворо однократним (Exact Sizing).

Порівняння скомпільованого байт-коду

Для простого методу:

public String concat(String first, int age) {
    return first + " is " + age;
}

Байт-код Java 8:

0: new           #2  // class java/lang/StringBuilder
3: dup
4: invokespecial #3  // Method java/lang/StringBuilder."<init>":()V
7: aload_1
8: invokevirtual #4  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
11: ldc           #5  // String  is 
13: invokevirtual #4  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
16: iload_2
17: invokevirtual #6  // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
20: invokevirtual #7  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
23: areturn

Мінуси: 8 інструкцій байт-коду, створення екземпляра StringBuilder, можливий resize буфера при викликах append.

Байт-код Java 9+ (Java 17/21):

0: aload_1
1: iload_2
2: invokedynamic #7,  0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;I)Ljava/lang/String;
7: areturn

Плюси: Лише 3 інструкції. Розмір байт-коду скоротився майже втричі. Створення проміжного StringBuilder повністю відсутнє.

Типові помилки розуміння оптимізацій

  1. Помилка: «Компілятор оптимізує оператор += у циклах»: Компілятор оптимізує виключно окремі вирази. Конкатенація всередині циклу перетворюється на повторні виклики invokedynamic на кожній ітерації, що призводить до $O(N^2)$ виділень пам’яті та копіювань.
  2. Помилка: «Змінна з модифікатором final завжди бере участь у Constant Folding»: Якщо final-змінна ініціалізується результатом виклику методу (наприклад, final String a = UUID.randomUUID().toString();), компілятор не знає її значення на етапі компіляції, тому оптимізація Constant Folding не застосовується.

🔴 Senior Level

Архітектура StringConcatFactory та механізм рецептів

Під час генерації байт-коду javac формує статичну метаінформацію — рядок-рецепт (Recipe String) і передає його як статичний аргумент Bootstrap-методу (BSM):

public static CallSite makeConcatWithConstants(
    MethodHandles.Lookup lookup,
    String name,
    MethodType concatType,
    String recipe,
    Object... constants)
  • Спецсимвол \1 кодує динамічний аргумент зі стека (aload, iload).
  • Спецсимвол \2 кодує константу з масиву constants.

Наприклад, для виразу "User: " + user + " (id=" + id + ")" рядок-рецепт має вигляд: \(\text{Recipe} = \text{"User: \textbackslash 1 (id=\textbackslash 1)"}\)

Стратегії генерації машинного коду в HotSpot

JVM керує способом виконання конкатенації через системну властивість: -Djava.lang.invoke.stringConcat=<strategy>

Стратегія Принцип роботи Характеристики
INLINE_SIZED_EXACT (За замовчуванням) Генерує високооптимізований MethodHandle, що обчислює точну довжину всіх операндів, виділяє byte[] необхідного розміру та копіює дані байт за байтом. Мінімальна кількість інструкцій, нуль зайвих копіювань, жодних проміжних об’єктів у Heap.
METHOD_HANDLE_INLINE_SIZED_EXACT Будує дерево комбінаторів MethodHandle (filterArguments, foldArguments). Працює без генерації анонімних класів на льоту, заощаджує пам’ять Metaspace.
BC_SB (Bytecode StringBuilder) Генерує байт-код на базі StringBuilder. Резервний (fallback) режим для налагодження або систем із суворими лімітами Metaspace.

Оптимізація примітивів без боксингу

У реалізації Java 8 при виклику sb.append(age) викликався перевантажений метод, який усередині нерідко звертався до Integer.toString(int) або створював проміжний масив символів. У StringConcatFactory:

  1. Тип операнда передається в сигнатурі виклику як примітив (I, J, Z).
  2. Згенерований код безпосередньо звертається до алгоритму Integer.stringSize(int) для швидкого підрахунку кількості цифр.
  3. Цифри записуються прямо в результуючий масив байтів через внутрішній низькорівневий метод Integer.getChars(int, int, byte[]).
  4. Результат: Нуль виділень пам’яті для об’єктів-обгорток java.lang.Integer і жодних тимчасових рядків!

Векторизація та SIMD у Compact Strings

Оскільки з Java 9 рядки зберігаються як масив байтів (byte[] value) із прапорцем кодування (coder: 0 для Latin-1, 1 для UTF-16), StringConcatFactory враховує прапорці операндів:

  • Якщо всі операнди Latin-1, виділяється масив розміру $\sum \text{length}_i$ з coder = 0.
  • Якщо хоча б один операнд UTF-16, розмір подвоюється, і встановлюється coder = 1. Копіювання байтів здійснюється через C2 intrinsic на базі векторних процесорних інструкцій (AVX-2, AVX-512 на архітектурі x86 або NEON на ARM64), які копіюють по 32 або 64 байти за один машинний такт.

4 Tricky Questions

1. Чому розробники Java замінили генерацію StringBuilder на invokedynamic (JEP 280), замість того щоб навчити javac одразу алокувати byte[] потрібного розміру?

Відповідь: Головна архітектурна причина — розв’язка байт-коду та рантайму (Bytecode Decoupling):

  1. Компілятор javac не повинен знати деталей внутрішньої реалізації HotSpot JVM. Якби javac генерував байт-код прямого звернення до byte[] value та поля coder, цей байт-код порушив би інкапсуляцію та перестав би працювати на інших JVM або при зміні внутрішнього представлення класу String.
  2. invokedynamic дозволяє JVM оновлювати стратегію конкатенації «на льоту» без повторної компіляції прикладних бібліотек. Наприклад, при оновленні з Java 11 на Java 21 додаток автоматично отримує прискорені SIMD-інструкції копіювання пам’яті, скомпільовані новим JIT-компілятором, хоча .class-файли були зібрані багато років тому.

2. Що відбудеться на рівні байт-коду та рантайму при обчисленні String s = "A" + 1 + "B" + 2?

Відповідь: Усі операнди в цьому виразі є константами часу компіляції (Compile-Time Constants). Відповідно до специфікації JLS §15.28, компілятор javac повністю згорне цей вираз під час компіляції (Constant Folding). У байт-коді не буде ані інструкції invokedynamic, ані виклику StringConcatFactory, ані створення StringBuilder. У пулі констант класу (Constant Pool) буде створено єдиний запис типу CONSTANT_String_info зі значенням "A1B2", який завантажиться однією інструкцією ldc #X.

3. Як компілятор обробляє багаторядкові текстові блоки (Text Blocks, Java 15+) і чи є у них накладні витрати порівняно зі звичайною конкатенацією?

Відповідь: Багаторядкові текстові блоки """ ... """ обробляються компілятором javac виключно на етапі компіляції:

  1. Компілятор визначає мінімальний спільний відступ усіх непорожніх рядків та видаляє його (Strip Incidental White Space).
  2. Замінює всі символи переведення рядка на єдиний стандартний символ \n незалежно від операційної системи, на якій виконується збирання проєкту.
  3. Інтерпретує escape-послідовності (наприклад, \ для скасування перенесення рядка).
  4. Результуючий рядок записується до Constant Pool як єдиний неподільний рядковий літерал. Накладні витрати в рантаймі становлять абсолютний нуль (0 алокацій, 0 операцій конкатенації), оскільки текстовий блок завантажується в пам’ять командою ldc як готовий об’єкт.

4. Який оверхед дає перший виклик конкатенації через invokedynamic і чому його не варто боятися?

Відповідь: Під час першого виконання конкретної інструкції invokedynamic відбувається фаза Bootstrap Linkage:

  1. JVM перемикається на виконання методу StringConcatFactory.makeConcatWithConstants.
  2. Фабрика генерує код класу-адаптера або будує ланцюжок MethodHandle.
  3. Точка виклику зв’язується у постійний CallSite. Ця процедура займає приблизно 1–5 мікросекунд процесорного часу (one-time cost). Проте під час усіх наступних мільярдів викликів процесор виконує скомпільований машинний код напряму. Ба більше, JIT-компілятор C2 інлайнить отриманий MethodHandle, усуваючи накладні витрати віртуальних викликів, що в довгостроковій перспективі забезпечує на 50–70% вищу продуктивність, ніж старий підхід зі StringBuilder.

🎯 Шпаргалка для інтерв’ю

30-секундна відповідь

«Компілятор Java оптимізує конкатенацію рядків на двох рівнях. По-перше, літерали та final-константи зшиваються ще на етапі компіляції через Constant Folding, потрапляючи в байт-код як один готовий рядок. По-друге, для динамічних змінних, починаючи з Java 9, компілятор генерує інструкцію invokedynamic (StringConcatFactory, JEP 280), яка в рантаймі точно розраховує розмір кінцевого масиву байтів, усуває боксинг примітивів і виділяє пам’ять під рядок за одну пряму алокацію без проміжних об’єктів StringBuilder».

Ключові тези для Senior-інтерв’ю

  1. JLS §15.28 Constant Folding: Застосовується лише тоді, коли операнди є константами часу компіляції (літерали, примітиви, final-змінні без динамічної ініціалізації).
  2. JEP 280 (Java 9+): Заміна жорстко закодованого байт-коду StringBuilder на invokedynamic makeConcatWithConstants.
  3. Recipe String: Рядок-рецепт конкатенації зі спецсимволами \1 (динамічні аргументи зі стека) та \2 (статичні константи).
  4. Точний розрахунок розміру (Exact Sizing): Відсутність зайвих повторних алокацій і копіювань масивів.
  5. No Boxing: Примітиви (int, long) записуються в масив байтів безпосередньо через Integer.getChars() без створення об’єктів Integer.
  6. Цикли з +=: Не оптимізуються компілятором автоматично! Для циклів використання StringBuilder залишається строго обов’язковим.

Червоні прапорці (Чого говорити категорично не можна)

  • ❌ Стверджувати, що javac у сучасних версіях Java перетворює конкатенацію на StringBuilder (у Java 9+ застосовується invokedynamic).
  • ❌ Вважати, що invokedynamic рятує від повільної роботи конкатенації в циклах (у циклах invokedynamic викликається заново на кожній ітерації з $O(N^2)$ алокацій).
  • ❌ Думати, що багаторядкові текстові блоки (""") зшиваються в рантаймі (вони згортаються в літерал на етапі компіляції).

Пов’язані питання