Как реализовать шаблон Singleton с помощью Record

Технически реализовать шаблон Singleton (Одиночка) с помощью Record можно, объявив константу экземпляра в public static final поле:

🟢 Junior Level

Технически реализовать шаблон Singleton (Одиночка) с помощью Record можно, объявив константу экземпляра в public static final поле:

public record AppConfig(String environment, int timeoutSeconds) {
    // Единственный глобальный экземпляр
    public static final AppConfig INSTANCE = new AppConfig("production", 30);
}

// Использование в коде:
AppConfig config = AppConfig.INSTANCE;
System.out.println(config.environment()); // production

Преимущества Record для конфигурационных синглтонов:

Неизменяемость (Immutability): Все поля Record неявно final, что исключает случайную модификацию настроек из параллельных потоков.
Потокобезопасная инициализация: Статическое поле инициализируется при загрузке класса в соответствии с гарантиями Java Memory Model (JMM).
Компактность: Автоматически генерируются геттеры, методы equals(), hashCode() и toString().

Однако на практике Record не является лучшим инструментом для создания синглтонов. Для классических Singleton в Java стандартом де-факто остаётся enum (по рекомендации Джошуа Блоха).

🟡 Middle Level

Ограничения Record при реализации Singleton

Попытка сделать из Record строгий классический Singleton сталкивается с рядом архитектурных ограничений спецификации Java:

1. Запрет на приватный конструктор в `public record` (JLS §8.10.4)

В обычном классе для защиты от создания дополнительных экземпляров конструктор делают приватным (private MySingleton()).
В public record это запрещено спецификацией:

public record AppConfig(String url) {
    // ❌ Ошибка компиляции: 
    // Access modifier must not be less accessible than the record class
    private AppConfig { ... } 
}

Канонический конструктор public record обязан иметь модификатор доступа не слабее самого класса (то есть public). Это означает, что любой разработчик может вызвать new AppConfig("other"), нарушив единственность экземпляра.

2. Защита через флаг в компактном конструкторе

Чтобы пресечь создание повторных экземпляров, приходится внедрять защиту времени выполнения:

public record AppConfig(String url) {
    public static final AppConfig INSTANCE = new AppConfig("https://api.prod.com");
    private static boolean initialized = false;

    public AppConfig {
        synchronized (AppConfig.class) {
            if (initialized) {
                throw new IllegalStateException("Singleton already initialized!");
            }
            initialized = true;
        }
    }
}

3. Сериализация и десериализация

В отличие от обычных классов, где десериализация обходит конструкторы через механизм Unsafe, при десериализации Record всегда вызывается канонический конструктор (JEP 395).
Без метода readResolve() процесс десериализации либо выбросит исключение из-за флага initialized, либо создаст дубликат экземпляра:

public record AppConfig(String url) implements Serializable {
    public static final AppConfig INSTANCE = new AppConfig("https://api.prod.com");

    // Обязателен для сохранения идентичности Singleton при десериализации:
    private Object readResolve() {
        return INSTANCE;
    }
}

🔴 Senior Level

Сравнительный анализ: Enum vs Record vs Classic Class

Критерий	`Enum` Singleton	`Record` Singleton	Обычный `Class` (Holder / DCL)
Гарантия единственности JVM	✅ Полная (на уровне спецификации)	❌ Частичная (требует ручных проверок)	⚠️ Ручная (приватный конструктор)
Защита от Reflection	✅ Абсолютная (JVM блокирует `newInstance`)	❌ Уязвима (требует guard-флагов)	❌ Уязвима
Сериализация	✅ Встроена по спецификации (по имени константы)	⚠️ Требует явного `readResolve()`	⚠️ Требует явного `readResolve()`
Ленивая загрузка (Lazy)	❌ Нет (инициализируется при первом обращении к enum)	✅ Да (через вложенный `Holder` класс)	✅ Да (Holder Idiom)
Истинное назначение	Одиночные сервисы и константы	Неизменяемые структуры данных (DTO/Value Objects)	Любые сложные сервисы с состоянием

Ленивая инициализация Record (Bill Pugh Singleton / Holder Idiom)

Если создание Record ресурсоёмко и требует отложенной инициализации:

public record HeavyweightService(String host, int port) {
    // Вложенный статический класс инициализируется только при первом вызове getInstance()
    private static class Holder {
        private static final HeavyweightService INSTANCE = 
            new HeavyweightService("10.0.0.1", 8080);
    }

    public static HeavyweightService getInstance() {
        return Holder.INSTANCE;
    }
}

Фаза инициализации класса Holder защищена механизмом блокировок загрузчика классов (Class Loader Initialization Lock, JLS §12.4.2), гарантируя потокобезопасность без использования synchronized или volatile.

Архитектурный вердикт: Почему Record не должен быть сервисом-синглтоном

В чистой архитектуре программного обеспечения существует разделение на:

Objects with Identity & Behavior (Сервисы/Агенты): Управляют процессами, удерживают ресурсы (пулы соединений, сокеты, потоки выполнения).
Value Objects / Data Carriers (Данные): Описывают факты, не имеют уникального поведения, сравниваются по значению.

Record задуман создателями Java именно как прозрачный контейнер данных (transparent carrier of shallowly immutable data). Использование Record в качестве сервиса-одиночки нарушает принцип единственной ответственности (SRP) и концептуальное назначение языка. Если вам нужен синглтон — используйте enum или доверьте управление жизненным циклом компонентов Inversion of Control (IoC) контейнеру (Spring, Micronaut).

4 каверзных вопроса

1. Почему нельзя сделать канонический конструктор приватным в `public record`?

Ответ:
Спецификация JLS §8.10.4 устанавливает фундаментальный принцип прозрачности Record: компоненты записи и их канонический конструктор должны иметь доступность не ниже, чем сама запись. Запись декларирует свой API через список компонентов в заголовке, поэтому клиенты, имеющие доступ к классу записи, обязаны иметь возможность свободно конструировать её экземпляры. Приватный конструктор возможен, только если весь Record объявлен как private внутри внешнего класса.

2. Как Reflection API ведёт себя при попытке взломать `Enum` Singleton и `Record` Singleton?

Ответ:

Для Enum: Метод Constructor.newInstance() при попытке инстанциировать enum выбрасывает IllegalArgumentException: Cannot reflectively create enum objects. Эта защита зашита непосредственно в байт-код ядра OpenJDK (java.lang.reflect.Constructor).
Для Record: Конструктор Record является обычным Java-конструктором. Рефлексия спокойно создаст второй экземпляр через recordClass.getDeclaredConstructor(...).newInstance(...), если в теле конструктора нет специальной защитной логики с выбрасыванием исключений.

3. Обязателен ли `readResolve()` для `Record`, если он реализует `Serializable` и используется как Singleton?

Ответ:
Да, абсолютно обязателен.
Спецификация десериализации Record (JEP 395) гласит, что поток байтов считывается и передаётся в качестве аргументов в канонический конструктор записи. В результате ObjectInputStream.readObject() всегда создаёт новый экземпляр в куче. Единственный способ вернуть исходную константу — объявить в Record метод:

private Object readResolve() {
    return INSTANCE;
}

JVM вызовет readResolve() сразу после создания временного объекта и подставит ссылку на INSTANCE.

4. Может ли Record Singleton содержать изменяемое состояние?

Ответ:
Поля самого Record являются строго final. Однако неизменяемость Record является мелкой (shallow immutability). Если компонентом Record является изменяемый объект (например, AtomicInteger или Map<String, Object>), синглтон сможет мутировать своё внутреннее состояние. Тем не менее, мутабельный синглтон на базе Record считается грубым антипаттерном.

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

Как сделать: Объявить public static final MyRecord INSTANCE = new MyRecord(...).
Главная проблема: В public record конструктор обязан быть public (JLS §8.10.4). Нельзя сделать конструктор приватным, поэтому любой клиент может создать второй экземпляр через new MyRecord().
Сериализация: Требует явной реализации readResolve(), иначе десериализация создаст новый объект через вызов канонического конструктора.
Reflection: Рефлексия способна легко создать дубликат Record-синглтона (в отличие от enum, где рефлексия заблокирована JVM).
Лучшая альтернатива: enum MySingleton { INSTANCE; } гарантирует 100% потокобезопасность, единственность экземпляра, защиту от рефлексии и корректную сериализацию “из коробки”.
Где Record к месту: В качестве неизменяемого объекта конфигурации (ConfigSnapshot), распространяемого как синглтон-константа.