---

🟢 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() полезен:

1. Чтение миллионов записей с повторяющимися значениями: статусы заказов ("NEW", "PROCESSING", "COMPLETED"), валюты ("USD", "EUR"), названия стран или городов.
2. Экономия памяти: если в памяти удерживается 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

1. JVM рассчитывает 32-битный хеш строки.
2. Обращается к глобальной нативной таблице StringTable.
3. Производит сравнение символов/байтов в корзине хеш-таблицы.
4. Возвращает ссылку на найденный объект или регистрирует новый.

Реальный производственный пример: импорт справочников

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):

1. JNI Transition Overhead: Переход через границу Java $\rightarrow$ Native C++ требует сохранения регистров процессора и проверки безопасных точек (Safepoints).
2. Блокировки в старых версиях (до Java 11): В Java 7 и 8 таблица StringTable была защищена глобальным мьютексом StringTable_lock. При параллельном вызове intern() из 64 рабочих потоков приложение упиралось в полку блокировок, и пропускная способность падала в десятки раз.
3. Современный 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():

1. Ссылка на строку регистрируется в нативной StringTable.
2. Garbage Collector не может собрать объект во время быстрого копирования в Eden, так как на него теперь ссылается нативная структура JVM.
3. Сборщику мусора приходится сканировать всю таблицу 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 по сравнению с системным String.intern()?

Ответ:

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

---

🎯 Шпаргалка для интервью

30-секундный ответ

«Метод String.intern() находит или регистрирует строку в системном String Pool и возвращает ссылку на канонический объект в памяти. Его стоит использовать только для долгоживущих строк с высокой степенью дублирования (справочники, страны, валюты, категории), где экономия памяти достигает 90%. Для уникальных строк (UUID, токены) вызов intern() категорически запрещен, так как он забивает StringTable и перегружает GC. В современных высоконагруженных системах в качестве прозрачной альтернативы рекомендуется включать -XX:+UseStringDeduplication в G1 GC».

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

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

Красные флаги (чего ни в коем случае нельзя говорить)

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

Ссылки на связанные темы

• Как работает String Pool
• В чём разница между созданием String через литерал и через new
• Может ли String Pool вызвать OutOfMemoryError
• Что такое String deduplication в G1 GC
• Где хранится String Pool (в какой области памяти)