Что такое иммутабельный (неизменяемый) объект

Если над иммутабельным объектом требуется совершить операцию модификации (например, изменить имя, добавить элемент или сдвинуть дату), метод не изменяет исходный объект, а конст...

🟢 Junior Level

Иммутабельный (неизменяемый / Immutable) объект — это объект, состояние (значения всех полей) которого не может быть изменено никаким способом после завершения его создания в конструкторе.

Если над иммутабельным объектом требуется совершить операцию модификации (например, изменить имя, добавить элемент или сдвинуть дату), метод не изменяет исходный объект, а конструирует и возвращает новый экземпляр с обновленными данными.

Суть в 30 секундах

Исходный объект всегда остается неизменным и потокобезопасным.
Классические примеры в JDK: String, классы-обертки примитивов (Integer, Double, Boolean), классы даты и времени Java 8 (LocalDate, LocalTime, Instant), BigDecimal, UUID, а также типы данных record (Java 14+).

// Простейший иммутабельный класс (Java 21):
public final class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }

    // Операция "модификации" возвращает НОВЫЙ объект:
    public Point move(int dx, int dy) {
        return new Point(this.x + dx, this.y + dy);
    }
}

Основные признаки иммутабельного класса

Отсутствуют любые методы-модификаторы (сеттеры setX(), методы добавления/удаления).
Все поля объявлены как private final.
Класс объявлен как final (или имеет только приватные конструкторы), чтобы запретить переопределение методов в подклассах.
Внутренние мутабельные объекты защищены с помощью защитного копирования (Defensive Copy).

🟡 Middle Level

Пять правил создания иммутабельного класса (Effective Java, Item 17)

Джошуа Блох сформулировал 5 обязательных правил создания надежных неизменяемых классов:

Не предоставлять методов-мутаторов: Никаких сеттеров или методов очистки.
Предотвратить переопределение методов: Объявить класс final либо сделать все конструкторы private со статическими фабричными методами (static of(...)).
Сделать все поля final: Это гарантирует соблюдение модели памяти Java Memory Model (JMM) и безопасную публикацию объекта между потоками без синхронизации.
Сделать все поля private: Защищает от прямого обращения к состоянию из внешнего кода.
Обеспечить исключительный доступ к любым мутабельным компонентам: Если класс содержит ссылки на изменяемые объекты (Date, List, int[]), они никогда не должны возвращаться наружу напрямую или сохраняться без защитной копии.

Shallow Immutability против Deep Immutability

Shallow Immutability (поверхностная неизменяемость): Все ссылки самого класса являются final, но объекты, на которые они указывают, можно изменить снаружи.
Deep Immutability (глубокая / транзитивная неизменяемость): Неизменяем весь граф объектов, достижимых из данного класса.

// ОШИБКА: Shallow Immutability (класс НЕ является по-настоящему иммутабельным!)
public final class Order {
    private final List<String> items; // final запрещает менять саму ссылку items

    public Order(List<String> items) {
        this.items = items; // ОШИБКА: внешняя ссылка сохранена напрямую!
    }

    public List<String> getItems() {
        return items; // ОШИБКА: ссылка утекла наружу!
    }
}

// Внешний код ломает инкапсуляцию Order:
List<String> list = new ArrayList<>();
list.add("Book");
Order order = new Order(list);
list.add("Car"); // Состояние Order изменилось извне!
order.getItems().clear(); // Состояние Order очищено!

Правильная реализация с защитным копированием:

public final class Order {
    private final List<String> items;

    public Order(List<String> items) {
        // Защитная копия на входе (List.copyOf возвращает иммутабельный список)
        this.items = List.copyOf(items); 
    }

    public List<String> getItems() {
        return items; // Безопасно, так как List.copyOf нельзя мутировать
    }
}

Современные рекорды (`record`, Java 16+)

Начиная с Java 16, ключевое слово record генерирует иммутабельные структуры данных без шаблонного кода:

public record User(String id, String email) {}

Компилятор автоматически делает класс final, все поля private final, генерирует канонический конструктор, методы доступа (id(), email()), а также equals(), hashCode() и toString().

🔴 Senior Level

Семантика Final-полей в Java Memory Model (JLS §17.5)

Иммутабельные объекты в Java обладают гарантией безопасной публикации (Safe Publication) без использования synchronized или volatile.

Согласно спецификации JMM:

Запись в final-поле в конструкторе связывается с операцией завершения конструктора отношением Freeze Action.
Компилятор и процессор вставляют барьер памяти (StoreStore-барьер) перед выходом из конструктора.
Поток, получивший ссылку на иммутабельный объект после завершения конструктора, гарантированно видит корректно инициализированные значения всех его final-полей, даже если ссылка была передана через гонку данных (Data Race) без синхронизации!

Катастрофа утечки ссылки `this` из конструктора (This Escape)

Гарантия JMM §17.5 действует строго при одном критическом условии: ссылка this не должна утекать во время выполнения конструктора:

public final class BrokenImmutable {
    private final int value;
    public static BrokenImmutable instance;

    public BrokenImmutable(int value) {
        this.value = value;
        // КАТАСТРОФА: утечка ссылки this до завершения конструктора!
        instance = this; 
        // Или передача в listener: eventBus.register(this);
    }
}

Если другой поток прочитает instance до того, как конструктор завершит фазу Freeze, он увидит объект с value = 0 (неинициализированное дефолтное состояние), разрушив гарантию потокобезопасности.

Влияние на Garbage Collector: Card Table Write Barriers

Иммутабельность дает колоссальное архитектурное преимущество для сборщика мусора (HotSpot GC):

Поколенческая гипотеза: Большинство объектов быстро умирают. Когда долгоживущий объект в Old Generation мутирует и начинает ссылаться на молодой объект в Eden, JVM вынуждена фиксировать эту межпоколенческую ссылку.
Card Marking Write Barrier: При каждой перезаписи ссылки процессором выполняется нативный барьер записи: байт в таблице карточек (Card Table) помечается как «грязный» (Dirty Card). Это отнимает такты CPU и шины памяти.
Иммутабельные объекты никогда не обновляют поля: Попав в Old Generation, иммутабельный объект гарантированно никогда не генерирует грязных карточек (Zero Card Table Overhead). Это снижает время фаз сканирования в G1, ZGC и Parallel GC.

Персистентные структуры данных (Persistent Data Structures)

При глубокой иммутабельности полное копирование больших коллекций ($O(N)$) становится неэффективным. Для этого применяются персистентные структуры данных со структурным разделением памяти (Structural Sharing), например Hash Array Mapped Trie (HAMT) в библиотеке Vavr. При добавлении элемента пересоздается только путь от корня дерева до нового листа ($O(\log N)$ узлов), а все остальные 99% дерева переиспользуются старой и новой версиями совместно без копирования.

4 Tricky Questions

1. Является ли класс, объявленный через ключевое слово `record`, гарантированно глубоко иммутабельным?

Ответ: Нет, не является. Ключевое слово record гарантирует только поверхностную (Shallow) неизменяемость:

Компилятор делает поля компонента private final и не генерирует сеттеры.
Однако если компонент рекорда является мутабельным объектом (например, record Order(String id, List<Item> items)), внешний код может беспрепятственно мутировать список: order.items().add(newItem).
Для обеспечения глубокой иммутабельности разработчик обязан вручную переопределить компактный конструктор рекорда и выполнить защитное копирование:
```
public record Order(String id, List<Item> items) {
    public Order {
        items = List.copyOf(items); // Защита от мутаций
    }
}
```

2. Обязательно ли помечать иммутабельный класс ключевым словом `final`? Как реализовать иммутабельность без `final`?

Ответ: Ключевое слово final на самом классе не является строго обязательным, если предотвратить наследование другим архитектурным способом:

Сделать все конструкторы класса приватными (private).
Предоставить создание экземпляров исключительно через статические фабричные методы:
```
public class ComplexNumber {
    private final double re;
    private final double im;

    private ComplexNumber(double re, double im) {
        this.re = re;
        this.im = im;
    }

    public static ComplexNumber of(double re, double im) {
        return new ComplexNumber(re, im);
    }
}
```
Поскольку ни один подкласс не сможет вызвать super() конструктор, наследование от такого класса становится физически невозможным, что полностью гарантирует защиту от подмены логики мутабельными наследниками.

3. Почему конструктор иммутабельного класса должен выполнять защитное копирование мутабельного аргумента ДО проверки его валидности (Time-of-Check to Time-of-Use Attack)?

Ответ: Это классическое правило безопасности (TOCTOU / Defect Prevention):

// ОШИБКА: уязвимо к атаке TOCTOU
public Period(Date start, Date end) {
    if (start.after(end)) throw new IllegalArgumentException();
    this.start = new Date(start.getTime()); // Копирование ПОСЛЕ проверки!
}

Если объект Date разделяется между потоками, то в многопоточной среде злоумышленник может изменить значение объекта start в промежутке между проверкой if и моментом копирования. Правило: Защитная копия обязана создаваться в первую очередь, и все проверки инвариантов должны выполняться над созданной локальной копией.

4. Может ли иммутабельный объект иметь изменяемые (мутабельные) приватные поля для внутренних оптимизаций?

Ответ: Да, может, если это не нарушает наблюдаемое извне состояние (Observable Immutability). Классический пример из JDK — класс java.lang.String:

Поле private int hash не является final.
При создании строки оно равно 0. Хеш вычисляется лениво при первом вызове метода hashCode() и сохраняется в это поле.
Поскольку вычисление детерминировано, и результат для внешнего наблюдателя всегда идентичен, объект остается абсолютно иммутабельным с точки зрения контракта. Важно: В многопоточной среде не-final поля ленивой инициализации требуют либо атомарности/идемпотентности (как в String.hash), либо использования volatile.

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

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

«Иммутабельный объект — это объект, состояние которого невозможно изменить после конструирования. Любая модификация возвращает новый экземпляр. Для его создания класс объявляют final, поля делают private final, исключают сеттеры, изолируют мутабельные поля защитными копиями и предотвращают утечку this из конструктора. Главные преимущества — абсолютная потокобезопасность без блокировок, безопасность использования в качестве ключей HashMap и снижение нагрузки на GC за счет отсутствия Write Barriers в Old Generation».

Ключевые тезисы для Senior-интервью

5 правил Блоха: final класс, private final поля, отсутствие мутаторов, defensive copy на входе и выходе, безопасная публикация.
JMM §17.5 Final Freeze: Гарантия корректной видимости final полей всеми потоками без барьеров синхронизации.
This Escape: Утечка this из конструктора разрушает гарантии безопасности JMM.
Records (Java 16+): Дают только shallow immutability; коллекции требуют List.copyOf в компактном конструкторе.
GC Card Table: Отсутствие мутаций в Old Gen исключает Card Marking, разгружая сборщик мусора.
Observable Immutability: Допускает мутабельные поля для ленивого кэширования (String.hash).

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

❌ Считать, что класс иммутабелен просто потому, что в нем нет сеттеров.
❌ Утверждать, что record всегда автоматически гарантирует глубокую иммутабельность (он не защищает вложенные мутабельные объекты).
❌ Забывать делать защитную копию коллекций в геттерах и конструкторах.
❌ Считать, что иммутабельность всегда снижает производительность (в многопоточном коде отсутствие блокировок дает огромный прирост).