Коли потрібно використовувати intern()

Метод String.intern() — це нативний метод класу java.lang.String, який виконує ручну реєстрацію рядка в String Pool (пулі рядків JVM) і повертає канонічне посилання на рядковий...

🟢 Junior Level

Метод String.intern() — це нативний метод класу java.lang.String, який виконує ручну реєстрацію рядка в String Pool (пулі рядків JVM) і повертає канонічне посилання на рядковий об’єкт із пулу.

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

Якщо рядок створюється динамічно під час виконання програми (наприклад, читається з бази даних, мережевого сокета, JSON-файлу або збирається через StringBuilder), він за замовчуванням створюється у звичайній купі (Regular Heap) і не потрапляє до String Pool автоматично.

Виклик str.intern() шукає рядок із таким самим вмістом у String Pool.
Якщо рядок уже присутній у пулі — повертається посилання на об’єкт із пулу (а дублікат зі звичайної купи стає сміттям і збирається GC).
Якщо рядка в пулі немає — поточний рядок додається до пулу, і повертається посилання на нього.

// Рядок прочитано із зовнішнього джерела (новий об'єкт у купі):
String fromDatabase = new String("ACTIVE"); 
String fromPool = "ACTIVE"; // Літерал у String Pool

System.out.println(fromDatabase == fromPool); // false (різні об'єкти!)

// Примусово беремо канонічний екземпляр із пулу:
String interned = fromDatabase.intern();
System.out.println(interned == fromPool);     // true (один і той самий об'єкт!)

Коли метод `intern()` корисний:

Читання мільйонів записів із повторюваними значеннями: статуси замовлень ("NEW", "PROCESSING", "COMPLETED"), валюти ("USD", "EUR"), назви країн або міст.
Економія пам’яті: якщо в пам’яті утримується 1 000 000 об’єктів Order, де в кожного є поле status, без інтернування в купі буде 1 000 000 дублюючих об’єктів String. З intern() буде рівно 1 об’єкт String у пулі та 1 000 000 посилань на нього.

Коли `intern()` категорично заборонений:

Унікальні ідентифікатори: UUID, email, номери паспортів, токени авторизації, часові мітки. Інтернування унікальних рядків забиває пул мільйонами записів, які ніколи не перевикористовуються повторно.

🟡 Middle Level

Архітектурний розбір механізму

Під капотом виклик intern() делегується віртуальній машині через Java Native Interface (JNI):

// OpenJDK: src/hotspot/share/prims/jvm.cpp
JVM_ENTRY(jstring, JVM_InternString(JNIEnv *env, jstring str))
  if (str == NULL) return NULL;
  oop string = JNIHandles::resolve_non_null(str);
  oop result = StringTable::intern(string, CHECK_NULL);
  return (jstring) JNIHandles::make_local(env, result);
JVM_END

JVM обчислює 32-бітний хеш рядка.
Звертається до глобальної нативної таблиці StringTable.
Здійснює порівняння символів/байтів у кошику хеш-таблиці.
Повертає посилання на знайдений об’єкт або реєструє новий.

Реальний виробничий приклад: імпорт довідників

package com.example.batch;

import com.example.model.CustomerRecord;
import org.springframework.stereotype.Service;

import java.io.BufferedReader;
import java.io.FileReader;
import java.util.ArrayList;
import java.util.List;

@Service
public class BigDataImportService {

    public List<CustomerRecord> parseCsvFile(String path) throws Exception {
        List<CustomerRecord> records = new ArrayList<>();
        
        try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
            String line;
            while ((line = reader.readLine()) != null) {
                String[] tokens = line.split(",");
                String id = tokens[0];
                
                // УВАГА: Країна та статус мають надзвичайно високу повторюваність!
                // Застосовуємо intern() для запобігання роздуванню купи:
                String country = tokens[1].intern();
                String status = tokens[2].intern();
                
                records.add(new CustomerRecord(id, country, status));
            }
        }
        return records;
    }
}

Ефект у продакшені: Під час завантаження 5 мільйонів рядків витрати пам’яті на зберігання країн та статусів падають зі 120 МБ до 40 КБ!

🔴 Senior Level

Проблеми продуктивності та Contention у багатопоточності

Хоча intern() заощаджує оперативну пам’ять, він створює суттєве навантаження на процесор (CPU overhead):

JNI Transition Overhead: Перехід через межу Java $\rightarrow$ Native C++ вимагає збереження регістрів процесора та перевірки безпечних точок (Safepoints).
Блокування у старих версіях (до Java 11): У Java 7 та 8 таблиця StringTable була захищена глобальним м’ютексом StringTable_lock. При паралельному виклику intern() із 64 робочих потоків застосунок упирався в блокування, і пропускна здатність падала в десятки разів.
Сучасний HotSpot (Java 11+): StringTable переписана на ConcurrentHashTable (JEP 341). Конкурентність покращилася завдяки lock-free пошуку, проте обчислення хешу та кеш-лінійна синхронізація ядер CPU все одно потребують процесорного часу.

Альтернатива 1: Пул на базі `ConcurrentHashMap` або Guava `Interner`

У високонавантажених системах замість засмічення глобальної StringTable JVM часто створюють локальні типізовані пули:

package com.example.util;

import com.google.common.collect.Interner;
import com.google.common.collect.Interners;

public class ScopedStringPool {

    // Створює пул на базі слабких посилань (Weak References):
    // Щойно сервіс завершить роботу, невикористовувані рядки самі видаляться GC!
    private static final Interner<String> WEAK_INTERNER = Interners.newWeakInterner();

    public static String intern(String value) {
        return WEAK_INTERNER.intern(value);
    }
}

Переваги Guava WeakInterner перед String.intern():

Ізольований у межах конкретного сервісу, не засмічує глобальний JVM-пул.
Не потребує налаштування прапорців JVM -XX:StringTableSize.
Використовує стандартні WeakReference у купі Java, спрощуючи профілювання через стандартні memory dumps.

Альтернатива 2: Автоматична дедуплікація G1 GC

Якщо в застосунку немає суворих вимог до миттєвого порівняння рядків через ==, ідеальне архітектурне рішення — повністю прибрати виклики intern() з бізнес-коду та увімкнути прапорець віртуальної машини:

-XX:+UseG1GC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3

Збирач сміття G1 автоматично знаходить рядки-дублікати в Old Generation під час фонової розмітки (Concurrent Marking).
Він перенаправляє посилання byte[] value на єдиний масив байтів.
Результат: Економія пам’яті співмірна з intern(), але в кодовій базі немає нативних викликів, немає ризику OutOfMemoryError через StringTable, і процесор застосунку не навантажується під час обробки бізнес-запитів!

4 Tricky Questions

1. Що станеться, якщо в багатопотоковому застосунку 100 потоків почнуть безперервно викликати `String.intern()` у Java 8 у порівнянні з Java 17/21?

Відповідь:

У Java 8: Застосунок зазнає найтяжчої деградації продуктивності через високий contention на нативному м’ютексі StringTable_lock. Таблиця рядків у Java 8 мала фіксовану кількість кошиків і вимагала монопольного блокування при модифікації. Потоки зависатимуть у станах BLOCKED та WAITING, спалюючи такти CPU в холостих спробах захоплення спінлока.
У Java 17/21: Завдяки JEP 341 таблиця StringTable була переписана на ConcurrentHashTable з безблокувальним читанням (lock-free read) і сегментованими блокуваннями при вставці. Масштабованість зросте в рази, затримок на глобальному м’ютексі не виникатиме, хоча накладні витрати на JNI та розрахунок хешів збережуться.

2. Чому виклик `String.intern()` для короткоживучих (ephemeral) рядків вважається антипатерном, що погіршує роботу Garbage Collector?

Відповідь: Короткоживучі рядки, що створюються всередині методів, виділяються в молодшому поколінні купи (Eden Space) і в нормі миттєво видаляються під час дешевого мінорного збирання сміття (Young GC). Якщо для такого рядка викликати intern():

Посилання на рядок реєструється в нативній StringTable.
Garbage Collector не може зібрати об’єкт під час швидкого копіювання в Eden, оскільки на нього тепер посилається нативна структура JVM.
Збирачу сміття доводиться сканувати всю таблицю StringTable на етапі очищення слабких посилань, що збільшує час паузи GC (STW Pause Time). Короткоживучі рядки повинні спокійно вмирати в Eden без інтернування.

3. Чому дорівнюватиме результат виразу `s1 == s2` у наступному коді, і чому:

String s1 = new StringBuilder("Ja").append("va").toString();
s1.intern();
String s2 = "Java";
System.out.println(s1 == s2);

Відповідь: У цьому конкретному випадку з високою ймовірністю повернеться false (хоча для довільного унікального слова на кшталт "MyUniqueCustomWord" повернулося б true). Тонкість із попередньо зареєстрованими літералами: Слово "Java" майже завжди вже зареєстроване в StringTable самою віртуальною машиною в момент старту JVM (наприклад, завантажувачами класів для системних властивостей java.version, java.vendor).

Тому s1.intern() знаходить у пулі раніше створений системний рядок і повертає посилання на нього.
Змінна s1 при цьому продовжує вказувати на об’єкт, створений StringBuilder у купі.
Літерал s2 = "Java" бере посилання з пулу.
У підсумку s1 (купа) та s2 (пул) — це різні об’єкти, і s1 == s2 дає false. (Якби код було написано з присвоєнням s1 = s1.intern(), результат гарантовано став би true).

4. У чому перевага створення локального пулу рядків через `ConcurrentHashMap` або Guava `Interner` у порівнянні з системним `String.intern()`?

Відповідь:

Контроль місткості та життєвого циклу: Локальний кеш (наприклад, на базі Caffeine або Guava) дозволяє встановити максимальний розмір (maximumSize), час застарівання (expireAfterAccess) або стратегію витіснення (LRU). Системний String Pool у JVM неможливо примусово очистити за квотою пам’яті.
Відсутність JNI-оверхеду: Доступ до Java ConcurrentHashMap виконується повністю в байткоді JVM і компілюється JIT/C2 компілятором з інлайнінгом методів, без дорогого перемикання контексту Java $\rightarrow$ Native.
Безпека JVM: Переповнення локального кешу не впливає на роботу системних завантажувачів класів та інших модулів застосунку.

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

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

«Метод String.intern() знаходить або реєструє рядок у системному String Pool і повертає посилання на канонічний об’єкт у пам’яті. Його варто використовувати тільки для довгоживучих рядків із високим ступенем дублювання (довідники, країни, валюти, категорії), де економія пам’яті сягає 90%. Для унікальних рядків (UUID, токени) виклик intern() категорично заборонений, оскільки він забиває StringTable і перевантажує GC. У сучасних високонавантажених системах як прозору альтернативу рекомендується вмикати -XX:+UseStringDeduplication у G1 GC».

Чек-лист ключових понять

Основне призначення: Дедуплікація рядків у купі для економії RAM.
Коли використовувати: Масове читання довідкових даних із низькою кількістю унікальних значень.
Коли НЕ використовувати: Унікальні ідентифікатори (UUID), динамічні URL, короткоживучі рядки.
JVM Internals: Виклик C++ методу StringTable::intern(). У Java 11+ масштабується через ConcurrentHashTable.
Сучасні альтернативи: Guava Interners.newWeakInterner() (локальний пул) або прапорець JVM -XX:+UseStringDeduplication.

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

❌ «Викликайте intern() для кожного створюваного рядка в застосунку» (Це призведе до перевантаження CPU та роздування таблиці рядків).
❌ «Рядки, інтерновані через intern(), живуть вічно й ніколи не збираються GC» (Починаючи з Java 7, рядки без сильних посилань збираються GC).
❌ «intern() працює швидше, ніж звичайне порівняння через equals()» (Сам виклик intern() на порядки повільніший за equals()).