Как создать иммутабельный класс в Java

Для создания иммутабельного (неизменяемого) класса в Java необходимо гарантировать, что состояние объекта не может быть изменено после его конструирования. Классический рецепт с...

🟢 Junior Level

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

Не предоставлять методы-мутаторы (сеттеры).
Предотвратить наследование — объявить класс как final (или сделать конструкторы private, предоставив статические фабричные методы).
Сделать все поля final — это гарантирует однозначную инициализацию и задействует барьеры памяти JMM для безопасной публикации.
Сделать все поля private — защитить прямой доступ к состоянию.
Обеспечить эксклюзивный доступ к мутабельным компонентам — выполнять глубокое или защитное копирование (defensive copy) на входе (в конструкторе) и на выходе (в геттерах).

Классический пример: Пользовательский класс

Рассмотрим класс UserProfile, содержащий как примитивные и неизменяемые типы (long, String), так и мутабельные объекты (List<String>):

package com.example.model;

import java.util.Collections;
import java.util.List;
import java.util.Objects;

// 1. Класс объявлен final — запрещено наследование
public final class UserProfile {
    // 2. Все поля private final
    private final long id;
    private final String username;
    private final List<String> roles;

    // 3. Инициализация всех полей через конструктор с защитным копированием
    public UserProfile(long id, String username, List<String> roles) {
        this.id = id;
        this.username = Objects.requireNonNull(username, "Username must not be null");
        // Защитная копия на входе: предотвращает модификацию исходного списка извне
        this.roles = (roles == null) ? List.of() : List.copyOf(roles);
    }

    // 4. Только методы чтения (геттеры), никаких сеттеров
    public long getId() {
        return id;
    }

    public String getUsername() {
        return username;
    }

    // 5. Возврат иммутабельного представления (List.copyOf уже возвращает unmodifiable list)
    public List<String> getRoles() {
        return roles;
    }
}

🟡 Middle Level

Работа с мутабельными полями и защитное копирование

Одной из самых распространённых ошибок при проектировании иммутабельных классов является сохранение прямой ссылки на изменяемый объект.

1. Коллекции

В Java 10+ стандартным и наиболее производительным способом создания защитной копии является метод List.copyOf(), Set.copyOf(), Map.copyOf(). Если переданная коллекция уже является иммутабельной коллекцией платформы, copyOf возвращает её же без выделения дополнительной памяти. До Java 10 применялся паттерн:

this.roles = Collections.unmodifiableList(new ArrayList<>(roles));

Обратите внимание: просто обернуть Collections.unmodifiableList(roles) без new ArrayList<>(roles) недостаточно, так как обёртка является лишь «представлением» (view), и модификация исходного списка из вызывающего кода сразу отразится на внутреннем состоянии класса!

2. Массивы

Массивы в Java всегда мутабельны, даже если ссылка на массив объявлена как final. При сохранении или возврате массива необходимо всегда вызывать .clone() или Arrays.copyOf():

public final class CryptographicKey {
    private final byte[] keyBytes;

    public CryptographicKey(byte[] keyBytes) {
        Objects.requireNonNull(keyBytes, "Key bytes must not be null");
        // Защитная копия на входе
        this.keyBytes = keyBytes.clone();
    }

    public byte[] getKeyBytes() {
        // Защитная копия на выходе
        return keyBytes.clone();
    }
}

3. Даты и время (Java 8+)

Использование старого класса java.util.Date требует обязательного создания копии через new Date(date.getTime()). В современном коде следует использовать иммутабельные классы пакета java.time: LocalDate, LocalDateTime, Instant, Duration.

Создание через Record (Java 14/16+)

Записи (record) в современном Java предоставляют лаконичный синтаксис для создания неизменяемых классов данных:

public record UserAccount(long id, String email, List<String> permissions) {
    // Компактный конструктор для валидации и защитного копирования
    public UserAccount {
        Objects.requireNonNull(email, "Email required");
        // Record по умолчанию сохраняет ссылку as-is, поэтому необходимо защитное копирование:
        permissions = (permissions == null) ? List.of() : List.copyOf(permissions);
    }
}

Важный нюанс: record гарантирует только «поверхностную» иммутабельность (shallow immutability). Поля в байткоде генерируются как private final, геттеры не имеют префикса get, а сам класс неявно наследуется от java.lang.Record и является final. Однако если компонент записи является мутабельным объектом (например, ArrayList или массив), защитное копирование в компактном конструкторе остаётся обязательным!

Паттерн Builder для сложных иммутабельных классов

Когда у иммутабельного класса много полей, телескопические конструкторы становятся неудобными. Стандартное решение — статический внутренний класс Builder:

public final class ServerConfig {
    private final String host;
    private final int port;
    private final int timeoutMs;
    private final boolean tlsEnabled;

    private ServerConfig(Builder builder) {
        this.host = builder.host;
        this.port = builder.port;
        this.timeoutMs = builder.timeoutMs;
        this.tlsEnabled = builder.tlsEnabled;
    }

    public String getHost() { return host; }
    public int getPort() { return port; }
    public int getTimeoutMs() { return timeoutMs; }
    public boolean isTlsEnabled() { return tlsEnabled; }

    public static class Builder {
        private String host = "localhost";
        private int port = 8080;
        private int timeoutMs = 5000;
        private boolean tlsEnabled = true;

        public Builder host(String host) {
            this.host = Objects.requireNonNull(host);
            return this;
        }

        public Builder port(int port) {
            if (port < 1 || port > 65535) throw new IllegalArgumentException("Invalid port");
            this.port = port;
            return this;
        }

        public Builder timeoutMs(int timeoutMs) {
            this.timeoutMs = timeoutMs;
            return this;
        }

        public Builder tlsEnabled(boolean tlsEnabled) {
            this.tlsEnabled = tlsEnabled;
            return this;
        }

        public ServerConfig build() {
            return new ServerConfig(this);
        }
    }
}

🔴 Senior Level

Семантика `final` полей в JMM (§17.5) и барьеры памяти

Java Memory Model (JSR-133) предоставляет специальные гарантии для final полей, известные как Final Field Semantics:

При создании объекта среда выполнения HotSpot выполняет так называемое действие Freeze Action в конце конструктора.
JIT-компилятор вставляет барьер памяти StoreStore между операцией инициализации final полей и записью ссылки на созданный объект в разделяемую переменную (публикацией).
Это гарантирует, что любой поток, получивший ссылку на объект после корректного завершения конструктора, гарантированно увидит проинициализированные значения всех final полей без необходимости синхронизации (synchronized, volatile или Lock).

[Поток 1: Конструктор]
  1. Запись field1 = val1
  2. Запись field2 = val2
  [Freeze Action: StoreStore Barrier]
  3. Публикация ссылки: sharedRef = this;
               │
               ▼ (Безопасная передача через память)
[Поток 2: Читатель]
  1. Чтение sharedRef
  [LoadLoad Barrier]
  2. Чтение sharedRef.field1 -> Гарантированно val1 (не дефолтные 0 или null!)

Критическая опасность: Утечка ссылки `this` (Constructor Escape)

Если ссылка на создаваемый объект утекает из конструктора до завершения Freeze Action, гарантии JMM полностью аннулируются:

public final class LeakingPublisher {
    private final int value;

    public LeakingPublisher(EventBus bus) {
        this.value = 42;
        // ОШИБКА: утечка 'this' до завершения конструктора!
        bus.registerListener(this); 
    }
    
    public int getValue() {
        return value;
    }
}

В чём угроза на уровне CPU: Без завершения конструктора компилятор или процессор имеют право переупорядочить инструкции: ссылка this может быть передана в EventBus до того, как запись this.value = 42 завершится в кэше L1. Другой рабочий поток в EventBus немедленно обратится к listener.getValue() и прочитает 0 (значение по умолчанию)!

Аппаратная когерентность кэшей (MESI) и производительность

В многопроцессорных архитектурах постоянное изменение полей объекта вызывает протокол MESI/MOESI:

Когда ядро процессора изменяет переменную в строке кэша (cache line), оно посылает сигнал RFO (Request For Ownership) другим ядрам, переводя их кэш-линии в состояние Invalid (I).
Это вызывает феномен Cache Bouncing и инвалидацию конвейера команд.
Напротив, неизменяемые объекты гарантируют, что строки кэша процессоров остаются в состоянии Shared (S) на всех ядрах. Чтение данных происходит параллельно на максимальной скорости кэша L1/L2 без межъядерной синхронизации и риска ложного разделения кэш-линий (False Sharing).

Альтернатива `final class`: Приватные конструкторы и фабрики

Объявление класса как final — самый простой, но не единственный способ запретить неконтролируемое наследование. Второй подход — приватный конструктор и публичные статические фабричные методы:

public class ComplexNumber {
    private final double real;
    private final double imaginary;

    // Приватный конструктор: запрещает наследование из внешних пакетов
    private ComplexNumber(double real, double imaginary) {
        this.real = real;
        this.imaginary = imaginary;
    }

    public static ComplexNumber of(double real, double imaginary) {
        return new ComplexNumber(real, imaginary);
    }

    public static ComplexNumber ofReal(double real) {
        return new ComplexNumber(real, 0.0);
    }
}

Преимущества перед final class:

Позволяет иметь внутренние или пакетно-приватные реализации/подклассы (например, специализированные оптимизированные варианты для нуля или единицы).
Даёт возможность кэшировать экземпляры (Flyweight / пулинг) внутри фабричного метода, чего не позволяет обычный оператор new.

Взлом иммутабельности через Reflection и Unsafe

Исторически поля private final можно было перезаписать через рефлексию:

Field field = UserProfile.class.getDeclaredField("username");
field.setAccessible(true);
field.set(profile, "hacked");

Однако:

JEP 403 (Java 16+ / Strong Encapsulation): Прямой вызов setAccessible(true) к внутренностям java.base бросает InaccessibleObjectException.
C2 JIT Constant Folding: Если HotSpot C2-компилятор видит обращение к final-полю проверенного иммутабельного класса, он оптимизирует чтение, выполняя constant folding (подставляя константу напрямую в ассемблерный код). Даже если поле будет физически перезаписано через Unsafe.putObject, скомпилированный код продолжит читать старое значение!

4 Tricky Questions

1. Почему Джошуа Блох считает альтернативой объявлению класса `final` закрытие конструкторов (`private`) и статические фабричные методы? В чём архитектурное преимущество?

Ответ: Объявление всех конструкторов private или package-private делает класс фактически закрытым для расширения внешними клиентами, так как подкласс не может вызвать super(). Архитектурные преимущества:

Гибкость полиморфизма: Пакет может содержать несколько закрытых подклассов (например, RegularImmutableMap и EmptyImmutableMap), скрытых от публичного API.
Кэширование и пулинг: Фабричный метод (valueOf(), of()) в отличие от конструктора не обязан создавать новый объект при каждом вызове (яркий пример — Boolean.valueOf(boolean) или BigDecimal.ZERO).
Именование: Фабричные методы имеют осмысленные имена (Complex.fromPolar(r, theta) vs Complex.fromCartesian(x, y)), предотвращая двусмысленность перегрузок конструктора.

2. Допустим, класс объявлен как `final`, все поля `private final`, геттеры не отдают прямых ссылок на мутабельные объекты, но один из методов кэширует вычисленный `hashCode` в не-final поле `int hash`. Является ли класс иммутабельным и потокобезопасным?

Ответ: Да, такой класс остаётся иммутабельным с точки зрения вызывающего кода (логическая иммутабельность, observational immutability). Именно так устроен класс java.lang.String. Поле hash объявляется как private int hash; (без final и даже без volatile). Потокобезопасность обеспечивается тем, что:

Вычисление хэш-кода является идемпотентной чистой функцией (один и тот же алгоритм всегда даёт одинаковое 32-битное число).
При одновременном вызове hashCode() из нескольких потоков может произойти гонка вычислений (benign race condition), но все потоки запишут одно и то же значение.
В Java запись 32-битного примитива int является атомарной по спецификации JMM (§17.7), поэтому появление искажённых половинчатых данных (torn read/write) исключено.

3. Что произойдёт на уровне JIT-компилятора C2, если попытаться изменить `final`-поле иммутабельного объекта через `sun.misc.Unsafe` или рефлексию? Будет ли новое значение видно во всех частях программы?

Ответ: Поведение будет непредсказуемым из-за оптимизаций JIT-компилятора C2:

Компилятор HotSpot считает поля, объявленные как final, неизменными константами (Compile-Time Constants или Trust Final Fields).
При оптимизации циклов или агрессивном инлайнинге геттеров компилятор сохраняет значение поля в регистре процессора или вообще заменяет обращение к памяти прямой константой (constant folding / dead code elimination).
При изменении значения в куче через Unsafe.putAddress() значение в оперативной памяти изменится, но JIT-скомпилированный код, работающий в соседнем цикле или методе, никогда не перечитает его из памяти и продолжит использовать старое закешированное значение. В результате программа окажется в состоянии рассинхронизации.

4. Как именно утечка ссылки `this` из конструктора ломает семантику `final`-полей по спецификации JMM §17.5? Приведите конкретный пример гонки данных.

Ответ: Спецификация JMM §17.5 гарантирует корректную видимость final-полей только при условии, что конструктор завершился нормально без утечки ссылки this. При утечке (например, передача this в слушатель событий, регистрация в статическом списке или запуск нового Thread(this).start() внутри конструктора) происходит следующее:

Действие Freeze Action ещё не выполнено компилятором, и барьер памяти StoreStore не установлен.
Процессор и компилятор имеют право произвести запись адреса ссылки на объект до завершения записи значений полей объекта в кэш.
Сторонний поток, перехвативший ссылку, обратится к final-полю и прочитает значение по умолчанию (0 для примитивов, null для ссылок). Спустя несколько наносекунд в том же потоке это же поле вернёт уже реальное значение, что нарушает фундаментальный инвариант неизменяемости.

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

5 шагов создания иммутабельного класса

Запретить наследование: модификатор final у класса либо private конструкторы + фабричные методы.
Все поля private final: инкапсуляция + запуск Freeze Action JMM.
Никаких сеттеров: состояние задаётся один раз в конструкторе.
Защитные копии на входе: List.copyOf(), clone() для массивов, new Date(date.getTime()).
Защитные копии на выходе: возврат unmodifiable-коллекций или клонов массивов.
Никаких утечек this: никогда не вызывать внешние методы и не стартовать потоки в конструкторе.

Сравнение подходов

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

❌ «Чтобы класс был иммутабельным, достаточно объявить все поля final» — грубейшая ошибка! Если поле ссылается на мутабельный ArrayList, любой клиент может вызвать getList().add() и изменить состояние объекта.
❌ «Коллекции в Record автоматически становятся иммутабельными» — неверно. record лишь делает поле ссылки final, сам переданный список остаётся изменяемым, если не сделать List.copyOf() в компактном конструкторе.
❌ «Массивы с модификатором final неизменяемы» — неверно. final замораживает только ссылку на массив, элементы массива по индексам можно свободно перезаписывать.
❌ «Защитную копию можно сделать через clone()» — опасно для нестандартных классов: метод clone() в Java архитектурно сломан (Effective Java Item 13). Для коллекций использовать copyOf(), для массивов — clone() допустим.