Краткий ответ

String в Java неизменяем: после создания его последовательность символов не меняется. Операции, которые выглядят как изменение строки, возвращают другую строку или тот же объект, если преобразование не требуется.

Это обеспечивает безопасное совместное использование строк, корректную работу строковых хешей и предсказуемость строковых ключей в коллекциях.

Исторический контекст

Неизменяемые строки позволяют Java безопасно переиспользовать строковые литералы через пул строк. Один объект может быть доступен из разных частей программы без риска, что один участник изменит его содержимое для остальных.

Такой подход также упрощает реализацию кэширования хеш-кода и использование строк в качестве ключей структур данных. Конкретное внутреннее представление символов зависит от версии JDK и не является частью контракта языка.

Постановка проблемы

Если бы содержимое String можно было менять после создания, строка, помещённая в HashMap или HashSet, могла бы перестать находиться по прежнему хеш-коду. То же касалось бы строковых литералов, имён классов, путей и других значений, которые могут использоваться несколькими компонентами.

Кроме того, передача изменяемой строки между компонентами создавала бы риск скрытого изменения данных. Неизменяемость устраняет этот класс побочных эффектов, но увеличивает число создаваемых объектов при большом количестве последовательных конкатенаций.

Подробное решение

У String нет публичных операций, изменяющих его символы. Методы вроде concat, replace и toUpperCase вычисляют результат и возвращают новый объект String либо возвращают исходный объект, если результат эквивалентен ему.

Ссылка на строку может быть переназначена, но это не меняет прежний объект:

String text = "Java";
text = text.toUpperCase();

System.out.println(text); // JAVA

В этом примере первая строка остаётся неизменной, а переменная начинает ссылаться на результат операции. Оператор + со строками также не изменяет существующие String; компилятор может оптимизировать выражение или использовать вспомогательный механизм конкатенации.

String объявлен как final, поэтому его нельзя унаследовать и переопределить поведение так, чтобы операция якобы изменяла внутреннее состояние. Его внутреннее состояние скрыто, а доступные операции сохраняют контракт неизменяемости.

Неизменяемость не означает, что переменная-ссылка неизменяема: ссылку можно переназначить, если она не объявлена final. Также String нельзя использовать как эффективный изменяемый буфер: для большого числа последовательных изменений обычно выбирают StringBuilder, а при необходимости синхронизации — StringBuffer.

Ситуация из практики

Сервис собирает длинное сообщение в цикле. Вариант с последовательным + прост для небольших выражений, но при множественных операциях может создавать много промежуточных строк. Вариант с StringBuilder уменьшает число временных объектов и обычно лучше подходит для построения результата в одном потоке.

Если сервис обрабатывает пароль, использование String удобно для API, но строку нельзя явно очистить после применения: её содержимое будет доступно до освобождения объекта сборщиком мусора. Если библиотека поддерживает массив символов, для краткоживущего секрета можно выбрать char[] и затереть его после использования, понимая, что копии данных всё равно могут существовать.

Практический выбор таков: String — для обычных текстовых значений, ключей и результатов; StringBuilder — для интенсивной сборки текста; массив символов — только когда API и требования к обработке секретов действительно это оправдывают.

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

Гарантирует ли final у переменной String неизменяемость текста?

Нет. final запрещает переназначить саму ссылку после инициализации, но не является причиной неизменяемости String. Неизменяемость обеспечивается устройством класса String и его публичным контрактом; даже обычная переменная String всё равно не может изменить уже созданный объект.

Всегда ли операция над строкой создаёт новый объект?

Нет. Реализация может вернуть исходный объект, если результат операции совпадает с ним, а компилятор и JVM могут выполнять оптимизации. Поэтому нельзя полагаться на создание нового объекта; для сравнения содержимого используют equals, а не ==.

Почему неизменяемость String важна для HashMap?

Хеш-таблица рассчитывает положение ключа на основе его hashCode. Если бы содержимое ключа и его хеш могли измениться после вставки, объект остался бы в старой корзине, а поиск по текущему значению мог бы его не обнаружить. Неизменяемость String гарантирует, что его содержимое и логический хеш не меняются в течение жизни объекта.