Почему про immutable-объект говорят «потокобезопасен без синхронизации»?
Модель памяти гарантирует: если все поля final и this не утёк из конструктора, любой поток, получивший ссылку на готовый объект, увидит поля проинициализированными — без синхронизации. Состояние не меняется, значит гонок нет.
- Гарантия final-полей (freeze) действует даже при публикации через гонку
- Без final объект «эффективно неизменяем» требует безопасной публикации
- Изменяемые элементы внутри ломают гарантию
А ещё Утечка this: регистрация слушателя или запуск потока в конструкторе
Подробно
Модель памяти Java гарантирует: у объекта со ВСЕМИ полями final, чья ссылка this не «утекла» из конструктора, любой поток, получивший ссылку на готовый объект, увидит его поля корректно проинициализированными — без блокировок. Это и делает «immutable ⇒ потокобезопасен». Подробный механизм — в уроке про JMM.
Что хотят услышать
- Гарантия final-полей.
- Условие неутечки this.
Частые ошибки
- Думать, что JVM сама синхронизирует immutable.
- Публиковать this из конструктора (ломает гарантию).
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗JVM автоматически синхронизирует доступ ко всем immutable-объектам
- ✗Любое чтение объекта в Java и так атомарно и сразу видимо всем потокам
- ✓Семантика final-полей гарантирует, что другой поток увидит их инициализированными
- ✗Неизменяемые объекты лежат в ThreadLocal, и другие потоки их не видят
Что спросят дальше
- Что значит «утечка this» из конструктора?
- Как это связано с happens-before?
Разбор темы
- Проектирование неизменяемых классов
Зачем нужна неизменяемость, рецепт immutable-класса, защитные копии, безопасная публикация и records.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.