---

Junior Level

Иммутабельные объекты потокобезопасны, потому что race condition требует как минимум одной записи и одного чтения. Если записей нет после создания — race condition физически невозможен.

public final class Config {
    private final String url;
    private final int timeout;

    public Config(String url, int timeout) {
        this.url = url;
        this.timeout = timeout;
    }

    public String getUrl() { return url; }
    public int getTimeout() { return timeout; }
    // Нет сеттеров — никто не может изменить состояние
}

Этот объект можно безопасно передавать между потоками — не нужны synchronized или Lock.

Важно: иммутабельность ≠ thread-safe для ссылок

Иммутабельный объект безопасен для чтения из многих потоков. Но если его поле ссылается на мутабельный объект — тот объект нужно защищать отдельно.

---

Middle Level

Отсутствие Race Condition

Race Condition возникает, когда потоки одновременно читают и записывают одни данные. Иммутабельный объект не позволяет писать — конфликты на запись физически невозможны.

Гарантии Java Memory Model для final полей

Даже если объект не меняется, существует риск увидеть его в частично инициализированном состоянии. Ключевое слово final предотвращает это:

• В конце конструктора происходит “заморозка” (freeze) всех final полей
• Любой поток, получивший ссылку на объект после завершения конструктора, увидит все final поля инициализированными
• Процессор и компилятор не могут переупорядочить инструкции так, чтобы ссылка стала доступна раньше установки final полей

Копирование при “изменении”

public final class Counter {
    private final int value;

    public Counter(int value) { this.value = value; }

    public Counter increment() {
        return new Counter(this.value + 1); // новый объект
    }
}

---

Senior Level

Семантика Freeze и Memory Barriers

Спецификация JLS (Java Language Specification) §17.5 гарантирует: после завершения конструктора все final поля видны любому потоку. Это обеспечивается memory barrier в конце конструктора, который:

1. Запрещает reorder инструкций за пределы барьера
2. Гарантирует видимость всех final полей
3. Создаёт safe publication без volatile или синхронизации

Объект vs Ссылка

Важно различать неизменяемость самого объекта и неизменяемость ссылки на него:

public class Service {
    private ImmutableObject data = new ImmutableObject("v1"); // Ссылка мутабельна!

    public void update(String val) {
        this.data = new ImmutableObject(val); // Не потокобезопасно без volatile/final
    }
}

Сам ImmutableObject потокобезопасен, но ссылка data — нет. Другие потоки могут видеть старую ссылку из своего кэша.

Паттерны использования

• Copy-On-Write — CopyOnWriteArrayList полагается на иммутабельность массивов
• Value Objects в DDD — неизменяемые объекты для передачи данных между слоями
• Actors / Event Sourcing — каждое событие иммутабельно, состояние пересчитывается

Резюме для Senior

• Потокобезопасность = отсутствие мутации + гарантии JMM для final полей
• Иммутабельность избавляет от накладных расходов на синхронизацию — lock-free доступ устраняет contention между потоками, который при высокой конкуренции может снизить throughput на 50-90%.
• Всегда используйте final для публикации иммутабельных объектов
• Для мутабельных ссылок на иммутабельные объекты используйте volatile или AtomicReference

---

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

Обязательно знать:

• Race condition невозможен — нет записи после создания объекта
• final поля обеспечивают safe publication — JLS §17.5, freeze в конце конструктора
• Memory barrier в конце конструктора запрещает reorder инструкций
• Иммутабельность ≠ thread-safe для ссылок: ссылка на объект может быть мутабельной
• Copy-On-Write паттерн — CopyOnWriteArrayList полагается на иммутабельность массивов
• Для мутабельных ссылок: volatile или AtomicReference

Частые уточняющие вопросы:

• Почему не нужен synchronized? — Нет записи = нет конкуренции за данные
• Что такое freeze в JMM? — Барьер памяти в конце конструктора, гарантирующий видимость final полей
• Может ли поток увидеть частично созданный объект? — Без final полей — да; с final — нет (safe publication)
• Что если ссылка на иммутабельный объект мутабельна? — Нужен volatile или AtomicReference для безопасной замены

Красные флаги (НЕ говорить):

• «Все объекты без сеттеров потокобезопасны» — мутабельные поля внутри всё ещё опасны
• «synchronized делает объект иммутабельным» — это про синхронизацию, а не про неизменяемость
• «final поля можно менять через reflection» — в Java 16+ это заблокировано для java.base
• «Иммутабельный объект = потокобезопасная ссылка» — сама ссылка может быть мутабельной

Связанные темы:

• [[1. Что такое иммутабельный (неизменяемый) объект]]
• [[2. Какие преимущества даёт использование иммутабельных объектов]]
• [[7. Что такое ключевое слово final и как оно помогает в создании иммутабельных классов]]
• [[23. Как иммутабельность влияет на производительность]]