🟢 Junior Level

Singleton — паттерн, который гарантирует, что у класса будет только один экземпляр.

Зачем: когда ресурс общий (лог-файл, подключение к БД, конфигурация) и несколько копий приведут к конфликтам или неконсистентному состоянию.

Простая аналогия: В стране может быть только один президент. Если вы спросите “кто президент?”, вам всегда назовут одного и того же человека.

Как работает:

1. Приватный конструктор (нельзя создать через new)
2. Статическое поле с единственным экземпляром
3. Статический метод для получения этого экземпляра

Пример:

public class Logger {
    // 1. Единственный экземпляр
    private static Logger instance = new Logger();
    
    // 2. Приватный конструктор
    private Logger() {}
    
    // 3. Метод для получения экземпляра
    public static Logger getInstance() {
        return instance;
    }
    
    public void log(String message) {
        System.out.println(message);
    }
}

// Использование — всегда один и тот же объект
Logger logger1 = Logger.getInstance();
Logger logger2 = Logger.getInstance();
System.out.println(logger1 == logger2); // true (один объект!)

Когда использовать:

• Логгер (один на всё приложение)
• Конфигурация (один файл настроек)
• Подключение к БД (пул соединений)

Singleton vs static class

Singleton может реализовать интерфейс (тестируемость через моки), static class — нет. Singleton поддерживает ленивую инициализацию, static class инициализируется при загрузке класса.

---

🟡 Middle Level

Реализации Singleton

1. Early Initialization (простая):

public class Singleton {
    private static Singleton instance = new Singleton(); // При загрузке класса
    private Singleton() {}
    public static Singleton getInstance() { return instance; }
}
// ✅ Потокобезопасна
// ❌ Не ленивая (создаётся даже если не нужна)

2. Lazy Initialization:

public class Singleton {
    private static Singleton instance;
    private Singleton() {}
    
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
// ✅ Ленивая
// ❌ Не потокобезопасна!

3. Thread-Safe (synchronized):

public class Singleton {
    private static Singleton instance;
    private Singleton() {}
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
// ✅ Потокобезопасна
// ❌ Медленная: synchronized добавляет ~10-50ns на каждый вызов, что критично в hot-path с миллионами вызовов.

4. Enum Singleton (лучшая):

public enum Singleton {
    INSTANCE;
    
    public void doWork() {
        System.out.println("Working...");
    }
}

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

Как можно “сломать” Singleton

1. Reflection:

// ❌ Обычный Singleton можно сломать
Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton fake = constructor.newInstance();  // Второй экземпляр!

// ✅ Enum защищён
Constructor<SingletonEnum> constructor = SingletonEnum.class.getDeclaredConstructor();
// → IllegalArgumentException: Cannot reflectively create enum objects

2. Serialization:

// ❌ При десериализации создаётся новый объект
ObjectOutputStream out = ...;
out.writeObject(Singleton.getInstance());

ObjectInputStream in = ...;
Singleton another = (Singleton) in.readObject();  // Новый объект!

// ✅ Решение: метод readResolve()
private Object readResolve() {
    return getInstance();  // Вернуть существующий
}

3. ClassLoader:

// Если несколько ClassLoader → несколько Singleton!
// Один в Tomcat, другой в OSGi

Singleton в Spring

// Spring управляет Singleton сам
@Component  // Singleton scope по умолчанию!
public class UserService { }

// Всегда один и тот же бин
@Autowired UserService service1;
@Autowired UserService service2;
// service1 == service2 → true

Типичные ошибки

1. Singleton вместо DI

   // ❌ Скрытая зависимость
   public class OrderService {
       public void create() {
           Logger.getInstance().log("...");  // Скрытая зависимость!
       }
   }
      
   // ✅ DI
   public class OrderService {
       private final Logger logger;
       public OrderService(Logger logger) { this.logger = logger; }
   }
   

2. Состояние в Singleton

   // ❌ Мутабельный Singleton = проблемы в многопоточности
   public class Counter {
       private int count = 0;  // Race condition!
       public void increment() { count++; }
   }
   

---

🔴 Senior Level

Контекстуальность Singleton

“Единственный экземпляр” — это относительно:

Контекст	Единственность
JVM	Один экземпляр на JVM
ClassLoader	Один на ClassLoader (может быть несколько!)
Spring Context	Один на ApplicationContext
Распределённая система	НЕ СУЩЕСТВУЕТ (нужна распределённая блокировка)

В кластере:

Node 1: Singleton instance A
Node 2: Singleton instance B
Node 3: Singleton instance C
→ 3 экземпляра! Нужен Redis/Zookeeper для координации

Java Memory Model и Singleton

JMM (Java Memory Model) — спецификация, определяющая, как потоки видят память друг друга. Bill Pugh Singleton — назван по имени исследователя, предложившего решение через static inner class. SRP (Single Responsibility Principle) — принцип единственной ответственности.

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

// ❌ Опасный код
public class UnsafeSingleton {
    private static UnsafeSingleton instance;
    
    public static UnsafeSingleton getInstance() {
        if (instance == null) {
            instance = new UnsafeSingleton();
        }
        return instance;
    }
}

// Поток 1: выделил память → опубликовал ссылку → вызвал конструктор
// Поток 2: видит instance != null → получает НЕИНИЦИАЛИЗИРОВАННЫЙ объект!

// ✅ Решение: volatile + double-checked locking
private static volatile UnsafeSingleton instance;

public static UnsafeSingleton getInstance() {
    UnsafeSingleton local = instance;
    if (local == null) {
        synchronized (UnsafeSingleton.class) {
            local = instance;
            if (local == null) {
                instance = local = new UnsafeSingleton();
            }
        }
    }
    return local;
}

Почему volatile критичен:

• Без volatile: инструкция reorder (выделение памяти → публикация → конструктор)
• С volatile: happens-before гарантия → конструктор ЗАВЕРШЁН до публикации

Singleton как Anti-pattern

Проблемы:

1. Tight Coupling

   // Зависимость не видна в сигнатуре
   public class OrderService {
       public void process() {
           Database.getInstance().save(...);  // Скрытая зависимость!
       }
   }
   

2. Тестируемость

   // ❌ Невозможно замокать
   @Test
   void testOrder() {
       // Singleton сохраняет состояние между тестами!
       // Невозможно подменить Database.getInstance()
   }
   

3. Нарушение SRP

   // Класс отвечает за:
   // 1. Бизнес-логику
   // 2. Управление своим жизненным циклом
   // 3. Конкурентный доступ
   

4. Memory Leak

   // Singleton живёт вечно (статическое поле)
   // В Tomcat при redeploy → старый ClassLoader не GC
   // → Metaspace Leak
   

Bill Pugh Singleton (Static Holder)

public class BillPughSingleton {
    private BillPughSingleton() {
        if (INSTANCE_HOLDER.INSTANCE != null) {
            throw new IllegalStateException("Already initialized");
        }
    }
    
    private static class INSTANCE_HOLDER {
        static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }
    
    public static BillPughSingleton getInstance() {
        return INSTANCE_HOLDER.INSTANCE;
    }
}

// JVM гарантирует:
// 1. Ленивость (класс загрузится только при первом вызове)
// 2. Потокобезопасность (инициализация класса thread-safe)
// 3. Без synchronized overhead

GC и Singleton

// Singleton НЕ будет удалён GC, пока:
// 1. Жив ClassLoader
// 2. Есть ссылка на статическое поле

// В стандартном Java: ClassLoader жив до конца процесса
// → Singleton живёт "вечно"

// В Tomcat/OSGi: ClassLoader может быть выгружен
// → Но Singleton мешает GC → Memory Leak

Production Experience

Реальный сценарий #1: Singleton убил тестируемость

• 500 тестов, все используют Config.getInstance()
• Проблема: тесты зависят друг от друга (общее состояние)
• Решение: мигрировали на Spring DI
• Результат: тесты изолированы, параллельный запуск

Реальный сценарий #2: Singleton в кластере

• ID генератор как Singleton
• Проблема: в кластере 5 нод → 5 генераторов → дубли ID!
• Решение: Redis INCR для генерации ID
• Урок: Singleton ≠ распределённая единственность

Best Practices

1. НЕ пишите Singleton вручную в Spring-приложениях
2. Используйте DI (@Component = Singleton scope)
3. Enum — safest для библиотек/SDK
4. Bill Pugh — для ленивой инициализации
5. Избегайте мутабельного состояния в Singleton
6. readResolve() для защиты от сериализации
7. Проверка в конструкторе для защиты от рефлексии
8. В кластере → Redis/Zookeeper для координации

Резюме для Senior

• Singleton ≠ распределённая единственность — только в рамках JVM
• Enum — единственная защита от reflection/serialization атак
• DI-контейнер заменяет ручные Singleton в 99% случаев
• Memory Model: volatile критичен для DCL
• Тестируемость: Singleton = враг #1 unit-тестов
• GC: Singleton живёт вечно → осторожно с ресурсами
• Bill Pugh = ленивость + потокобезопасность без synchronized
• Скрытые зависимости = tight coupling = technical debt

---

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

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

• Singleton гарантирует единственный экземпляр класса через приватный конструктор + статический метод доступа
• Enum Singleton — самый безопасный: защита от reflection и сериализации “из коробки”
• Bill Pugh (Static Holder) — ленивая инициализация без synchronized, через static inner class
• В Spring @Component = Singleton scope по умолчанию, НЕ пишите Singleton вручную
• Singleton не работает в кластере — каждая нода создаёт свой экземпляр
• Без volatile в DCL возможен reordering: поток получит неинициализированный объект
• Singleton считается антипаттерном: нарушает SRP, DIP, тестируемость

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

• Как “сломать” Singleton? — Reflection (создать новый экземпляр), сериализация (десериализация создаёт новый объект), ClassLoader (несколько загрузчиков)
• Почему Enum лучше обычного Singleton? — JVM запрещает reflectively создавать enum, сериализация корректна
• Когда Singleton допустим? — Логгеры, конфигурация, кэши — stateless или иммутабельные объекты
• Что такое Bill Pugh Singleton? — Ленивая инициализация через static inner class, JVM гарантирует потокобезопасность

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

• “Я использую Singleton для хранения состояния в Spring” — Spring управляет этим через DI
• “Singleton работает в кластере” — каждая нода создаёт свой экземпляр
• “Мой Singleton потокобезопасен без volatile” — DCL без volatile = undefined behavior
• “Singleton — это лучший паттерн” — это один из самых критикуемых паттернов

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

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