Ответ на вопрос.

История вопроса

До обновления Java 8, 20, разработчики, стремящиеся уменьшить потребление кучи из-за дубликатов объектов String, были вынуждены полагаться исключительно на String.intern(). Этот метод помещал строки в постоянное поколение (позже в Metaspace), требуя явных вызовов API и потенциально вызывая давление на память в пуле интернированных строк. С JEP 192 сборщик мусора G1 представил автоматическую дедупликацию строк, оптимизацию, направленную на распространенную проблему избыточных массивов символов в корпоративных приложениях.

Проблема

В Java-приложениях, интенсивно работающих с данными, таких как те, которые разбирают XML, JSON или результаты запросов к базам данных, объекты String часто составляют 25-50% живой кучи. Значительная доля этих строк идентична по символам, но находится в разных массивах char[] (или byte[] после Java 9 с Compact Strings). Без вмешательства эти дублирующие массивы тратят память и увеличивают частоту сборки мусора. Задачей было устранить эту избыточность без введения дополнительных пауз остановки мира или изменения кода.

Решение

G1 выполняет дедупликацию оппортунистично во время существующей пауз эвакуации (когда потоки уже остановлены). Когда это включено с помощью -XX:+UseStringDeduplication, сборщик сканирует объекты в молодом поколении. Для каждой строки, которая пережила по меньшей мере -XX:StringDeduplicationAgeThreshold сборок мусора (по умолчанию 3), G1 вычисляет хеш ее массива-задачи. Затем он консультируется с таблицей дедупликации. Если существует идентичный массив, G1 использует операцию сравнить-и-заменить (CAS), чтобы перенаправить поле value строки на существующий массив, позволяя дублирующимся строкам быть освобожденными в следующем цикле. Это использует существующую паузу, добавляя только незначительные накладные расходы на ЦП.

// Изменения в коде не требуются; флаги JVM включают оптимизацию:
// -XX:+UseG1GC -XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3
public class DeduplicationExample {
    public static void main(String[] args) {
        // Эти две строки разделяют один и тот же массив-задачу после дедупликации
        String a = new String("FinancialInstrument".toCharArray());
        String b = new String("FinancialInstrument".toCharArray());
        
        // После достаточного числа циклов сборки мусора и пауз эвакуации,
        // a.value == b.value (равенство внутренней ссылки массива)
    }
}

Ситуация из жизни

Платформа высокочастотной торговли, обрабатывающая сообщения протокола FIX, испытывала серьезные паузы G1, превышающие 200 мс. Профилирование показало, что 30% кучи в 64 ГБ потребляли объекты String, представляющие стандартные теги (например, "55", "150", "EUR/USD") и значения, подобные перечислениям, разобранные из входящих байт-потоков. Каждая инстанциация сообщения создавала новые экземпляры String через new String(byte[], Charset), что приводило к миллионам дублирующих массивов за минуту.

Несколько решений были оценены. String.intern() был отклонен, поскольку он требовал инвазивных изменений в более чем 50 типах сообщений и рисковал насыщением Metaspace постоянными ссылками, которые никогда не подлежат сборке мусора. Кэш на основе WeakHashMap был прототипирован, но он вводил сложные накладные расходы на параллелизм и логику очистки устаревших записей, которые парадоксально увеличивали давление на GC из-за дополнительной обработки WeakReference.

Команда в конечном итоге включила G1 дедупликацию строк с порогом возраста по умолчанию в 3. Этот прозрачный подход не потребовал изменений в коде и работал во время существующих пауз эвакуации, избегая любых новых фаз остановки мира.

Результатом стало снижение использования кучи на 22% и сокращение пауз 95-го процентиля до менее чем 50 мс. Накладные расходы на ЦП составили около 1,5% в часы пикового рынка, что является приемлемым компромиссом для экономии памяти и улучшения задержки.

Что кандидаты часто упускают

Как дедупликация строк взаимодействует с Compact Strings в Java 9, которые хранят текст в латинице как byte[], а не char[]?

Ответ. Дедупликация строк была обновлена для работы с массивами byte[], когда включены Compact Strings (по умолчанию с Java 9). Логика дедупликации проверяет поле coder (LATIN1 или UTF16) и хеширует соответствующий массив byte[] или char[]. Таблица дедупликации хранит записи с ключами на основе как хешей, так и типов массивов, что гарантирует, что строки латиницы дедуплицируются по отношению к другим строкам латиницы, а полноценные строки UTF-16 - по отношению к своим аналогам. Кандидаты часто ошибочно полагают, что эта функция была устаревшей с Compact Strings, но она остается полностью совместимой.

Почему JVM накладывает порог возраста (по умолчанию 3 GC) перед тем, как строка станет подходящей для дедупликации?

Ответ. Порог возраста предотвращает утомление ЦП циклами дедупликации однозначно короткоживущих, эфемерных строк, которые, вероятно, исчезнут в следующей молодой коллекции. Требуя, чтобы String пережил несколько циклов эвакуации G1 (продвигаясь от Eden к областям Survivor и в конечном итоге к Tenured), эвристика гарантирует, что только "взрослые" строки — те, которые имеют высокую вероятность долгосрочного выживания — обрабатываются. Это амортизирует стоимость вычисления хеша и поиска в таблице на ожидаемое время жизни объекта.

Влияет ли дедупликация строк на неизменяемость или стабильность hashCode экземпляра String?

Ответ. Нет. Процесс дедупликации является исключительно деталью реализации изменения ссылки поля value. Поскольку заменяемый массив содержит идентичные байты или символы, логическое состояние String и его hashCode остаются без изменений. hashCode кэшируется в транзитном поле внутри самого объекта String, и поскольку содержимое идентично, кэшированное значение остается действительным. Контракт equals сохраняется, поскольку равенство содержимого подразумевает, что равенство ссылок на основное хранилище не имеет значения для контрактов API. Операция атомарна с точки зрения приложения, поддерживая гарантии неизменности String.