🟢 Junior Level

Если два потока одновременно проверят instance == null, оба создадут свой объект — получится два экземпляра вместо одного. Чтобы Singleton работал в многопоточной среде, нужно защитить создание экземпляра.

Простая проблема:

// ❌ Два потока могут одновременно создать два экземпляра!
if (instance == null) {
    instance = new Singleton();  // Поток 1 и Поток 2 одновременно!
}

Самый простой способ — Enum:

public enum Singleton {
    INSTANCE;  // JVM гарантирует один экземпляр
    
    public void doWork() {
        System.out.println("Working...");
    }
}

// Использование
Singleton.INSTANCE.doWork();
// ✅ Потокобезопасно, защита от рефлексии и сериализации

Почему Enum безопасен:

• Java запрещает создание enum через new
• Сериализация работает корректно
• Многопоточность обеспечена JVM

Когда НЕ реализовывать потокобезопасный Singleton вручную

В Spring-приложениях: @Component + singleton scope (по умолчанию) уже управляет этим. В CDI: @ApplicationScoped. Не изобретайте велосипед.

---

🟡 Middle Level

Способ 1: Enum Singleton (Рекомендуемый)

public enum Singleton {
    INSTANCE;
    
    private final String config;
    
    Singleton() {
        this.config = loadConfig();
    }
    
    public String getConfig() {
        return config;
    }
}

Преимущества:

• ✅ Потокобезопасен (JVM)
• ✅ Защита от reflection
• ✅ Защита от сериализации
• ✅ Простой код

Недостатки:

• ❌ Не ленивый (создаётся при загрузке класса)

Способ 2: Bill Pugh (Static Holder)

public class BillPughSingleton {
    private BillPughSingleton() {}
    
    // Вложенный класс загрузится только при первом обращении
    private static class SingletonHolder {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }
    
    public static BillPughSingleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
    
    // Защита от сериализации
    protected Object readResolve() {
        return getInstance();
    }
}

Почему работает:

• JVM гарантирует атомарность инициализации статических полей
• Класс SingletonHolder загрузится только при первом вызове getInstance()
• Ленивая инициализация без явного synchronized — потокобезопасность обеспечивается ClassLoader locking (JLS §12.4.2).

Способ 3: Double-Checked Locking

public class DclSingleton {
    private static volatile DclSingleton instance;
    
    private DclSingleton() {
        if (instance != null) {
            throw new IllegalStateException("Already created");
        }
    }
    
    public static DclSingleton getInstance() {
        DclSingleton local = instance;  // Оптимизация
        if (local == null) {
            synchronized (DclSingleton.class) {
                local = instance;
                if (local == null) {
                    instance = local = new DclSingleton();
                }
            }
        }
        return local;
    }
}

Зачем volatile:

• Без volatile возможен reordering
• Поток может получить ссылку на НЕИНИЦИАЛИЗИРОВАННЫЙ объект
• volatile запрещает переупорядочивание

До Java 5 (JSR-133) Memory Model не гарантировала happens-before для volatile, и DCL был сломан.

Сравнение

Способ	Ленивость	Потокобезопасность	Сложность
Enum	❌ Нет	✅ Полная	Минимальная
Bill Pugh	✅ Да	✅ Полная	Низкая
DCL + volatile	✅ Да	✅ Полная	Высокая

В Spring

// НЕ нужно писать Singleton вручную!
@Component  // Singleton scope по умолчанию
public class UserService { }

// Spring сам гарантирует один экземпляр
// + тестируемость через DI

---

🔴 Senior Level

Java Memory Model Deep Dive

Проблема без volatile:

// instance = new Singleton() состоит из 3 шагов:
// 1. Allocate memory
// 2. Invoke constructor  
// 3. Assign reference to instance

// Без volatile возможен reorder: 1 → 3 → 2
// Поток B видит instance != null на шаге 3
// Но конструктор (шаг 2) ещё не выполнен!
// → Поток B получает объект с дефолтными полями!

volatile решает:

// volatile вставляет Memory Barriers:
// StoreStore перед записью в volatile
// LoadLoad после чтения из volatile

// Это гарантирует:
// Все записи в конструкторе завершены ДО публикации ссылки

Local Variable Optimization:

public static DclSingleton getInstance() {
    DclSingleton local = instance;  // Читаем volatile ОДИН раз
    if (local == null) {
        synchronized (DclSingleton.class) {
            local = instance;
            if (local == null) {
                instance = local = new DclSingleton();
            }
        }
    }
    return local;  // Используем локальную переменную
}

// Без оптимизации: 2 чтения volatile (медленно)
// С оптимизацией: 1 чтение volatile (быстрее на ~25%)

VarHandle (Java 9+)

// Для экстремальной производительности
public class VarHandleSingleton {
    private static final VarHandle HANDLE = MethodHandles.lookup()
        .findStaticVarHandle(VarHandleSingleton.class, "instance", VarHandleSingleton.class);
    
    private static VarHandleSingleton instance;
    
    public static VarHandleSingleton getInstance() {
        VarHandleSingleton local = (VarHandleSingleton) HANDLE.getAcquire();
        if (local == null) {
            synchronized (VarHandleSingleton.class) {
                local = (VarHandleSingleton) HANDLE.getAcquire();
                if (local == null) {
                    local = new VarHandleSingleton();
                    HANDLE.setRelease(null, local);
                }
            }
        }
        return local;
    }
}

// getAcquire/setRelease дешевле volatile
// Но достаточно для DCL семантики

Initialization-on-demand Holder: Internal Mechanics

// JVM Class Loading механизм:
// 1. Класс загружается при первом обращении
// 2. Инициализация статических полей = атомарна
// 3. ClassLoader内部的 locking гарантирует thread-safety

// Это НЕ "магия" — это JLS (Java Language Specification) §12.4.1:
// "Initialization of a class consists of executing its static initializers"
// "The Java programming language implements multiple-threaded initialization correctly"

Protection from All Attacks

public class SecureSingleton implements Serializable {
    private static final SecureSingleton INSTANCE = new SecureSingleton();
    
    private SecureSingleton() {
        if (INSTANCE != null) {
            throw new IllegalStateException("Singleton violation");
        }
    }
    
    public static SecureSingleton getInstance() {
        return INSTANCE;
    }
    
    // Защита от сериализации
    private Object readResolve() throws ObjectStreamException {
        return INSTANCE;
    }
    
    // Защита от клонирования
    @Override
    protected Object clone() throws CloneNotSupportedException {
        throw new CloneNotSupportedException("Singleton cannot be cloned");
    }
}

Performance Comparison

Benchmark (10M calls):
  Enum:              10ms  (static final, JVM оптимизирует)
  Bill Pugh:         12ms  (класс loading один раз)
  DCL + volatile:    15ms  (volatile read overhead)
  VarHandle:         11ms  (weaker barriers)
  synchronized:      150ms (lock overhead каждый раз!)

Production Experience

Реальный сценарий: DCL без volatile в production

• Приложение работало 2 года без проблем
• После миграции на новый JDK → случайные NPE
• Причина: JDK изменил стратегию JIT оптимизации
• Решение: добавили volatile → проблема ушла

Best Practices

1. Enum — для 99% случаев (безопасность > ленивость)
2. Bill Pugh — когда критична ленивость
3. DI Container — в Spring-приложениях (НЕ пишите вручную!)
4. volatile ОБЯЗАТЕЛЕН в DCL
5. Local variable optimization в DCL
6. readResolve() для защиты от сериализации
7. Проверка в конструкторе для защиты от reflection
8. VarHandle (Java 9+) для экстремальной производительности

Резюме для Senior

• JMM: volatile запрещает reordering через Memory Barriers
• Bill Pugh: relies on JLS §12.4.1 guarantees
• Enum: нативная защита от reflection/serialization
• Local variable: снижает volatile reads на 25%
• VarHandle: weaker barriers → faster than volatile
• Spring: НЕ пишите Singleton — используйте @Component
• DCL без volatile = бомба замедленного действия

---

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

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

• Enum Singleton — рекомендуемый способ: потокобезопасен, защищён от reflection и сериализации
• Bill Pugh (Static Holder) — ленивая инициализация без synchronized, через static inner class (JLS 12.4.1)
• Double-Checked Locking требует volatile для запрета instruction reordering
• Local variable optimization в DCL снижает volatile reads на 25%
• В Spring-приложениях НЕ пишите Singleton вручную — @Component с singleton scope
• VarHandle (Java 9+) предоставляет getAcquire/setRelease — дешевле volatile
• Без volatile: reordering 1→3→2 (memory → publish → constructor) → неинициализированный объект

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

• Почему volatile обязателен в DCL? — Без него JIT/процессор может переупорядочить: выделить память → опубликовать ссылку → вызвать конструктор
• Как работает Bill Pugh? — Вложенный класс загружается только при первом обращении, JLS гарантирует атомарность инициализации
• Enum vs Bill Pugh — что выбрать? — Enum если не нужна ленивость, Bill Pugh если ленивость критична
• Почему Spring не требует ручного Singleton? — @Component с singleton scope, + тестируемость через DI

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

• “В Spring я пишу Singleton вручную через synchronized” — @Component уже управляет этим
• “Volatile не нужен, у меня работает” — reordering проявляется только на определённых CPU/JDK
• “DCL без volatile безопасен” — undefined behavior, особенно на ARM процессорах
• “Enum не подходит для Singleton” — это рекомендуемый Joshua Bloch способ

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

• [[3. Что такое Singleton]] — общее описание паттерна
• [[5. Что такое double-checked locking]] — подробнее о DCL
• [[6. Каковы проблемы с Singleton]] — проблемы Singleton
• [[2. Какие категории паттернов существуют]] — Creational паттерны
• [[16. Какие антипаттерны вы знаете]] — когда Singleton становится антипаттерном