🟢 Junior Level

Проблемы Singleton делятся на три категории: тестируемость (невозможно замокать), архитектура (скрытые зависимости), инфраструктура (проблемы с масштабированием).

1. Трудно тестировать — нельзя подменить на мок
2. Скрытые зависимости — не видно, что класс использует Singleton
3. Глобальное состояние — тесты влияют друг на друга
4. Не масштабируется — в кластере будет по Singleton на каждую ноду

Пример проблемы:

// ❌ Singleton мешает тестам
public class OrderService {
    public void create() {
        Database.getInstance().save(...);  // Реальная БД!
    }
}

@Test
void testOrder() {
    // Невозможно подменить Database на тестовую!
    // Тест идёт в реальную БД
}

Решение: Вместо ручного Singleton используйте DI-контейнер (Spring), который управляет единственностью экземпляра за вас. Spring @Component + singleton scope = тот же Singleton, но тестируемый.

---

🟡 Middle Level

1. Проблемы с тестированием

Flaky Tests — тесты, которые случайно проходят/падают без изменения кода.

// ❌ Singleton = Flaky Tests
@Test
void test1() {
    Counter.getInstance().increment();
    assertEquals(1, Counter.getInstance().getCount());
}

@Test 
void test2() {
    // Счётчик уже = 1 из test1!
    assertEquals(1, Counter.getInstance().getCount()); // FAIL!
}

// ✅ Решение: DI
public class Counter {
    private int count = 0;
    public void increment() { count++; }
    public int getCount() { return count; }
}

@Test
void test1() {
    Counter counter = new Counter();  // Новый для каждого теста
    counter.increment();
    assertEquals(1, counter.getCount());
}

2. Tight Coupling

// ❌ Зависимость скрыта
public class OrderService {
    public void process() {
        Logger.getInstance().log("...");       // Скрытая зависимость
        Config.getInstance().getTimeout();     // Ещё одна
        Cache.getInstance().get("key");        // И ещё
    }
}
// Глядя на конструктор — не понятно, что нужно для работы!

// ✅ Явные зависимости через конструктор
public class OrderService {
    private final Logger logger;
    private final Config config;
    private final Cache cache;
    
    public OrderService(Logger logger, Config config, Cache cache) {
        this.logger = logger;
        this.config = config;
        this.cache = cache;
    }
}
// Сразу видно, что нужно для работы

3. Конкуренция за блокировки

// ❌ Singleton с состоянием = bottleneck
public class SessionManager {
    private final Map<String, Session> sessions = new HashMap<>();
    
    public synchronized void addSession(String id, Session session) {
        sessions.put(id, session);  // Все потоки ждут!
    }
}

// При 1000 запросов/сек → очередь к synchronized методу

4. Memory Leaks

Metaspace — область памяти JVM для метаданных классов.

// Singleton живёт вечно
public class DataLoader {
    private static DataLoader instance;
    private List<Data> cache = new ArrayList<>();  // Растёт!
    
    private DataLoader() {}
    public static DataLoader getInstance() {
        if (instance == null) instance = new DataLoader();
        return instance;
    }
}

// В Tomcat при redeploy:
// Старый ClassLoader не GC → Metaspace Leak
// → OutOfMemoryError: Metaspace

5. Не работает в кластере

Node 1: Singleton → counter = 1
Node 2: Singleton → counter = 1
Node 3: Singleton → counter = 1

// Думали: один счётчик на все ноды
// Реальность: по счётчику на каждую ноду!

Решение: Dependency Injection

// Spring управляет жизненным циклом
@Component
public class UserService {
    private final UserRepository repo;
    
    public UserService(UserRepository repo) {
        this.repo = repo;  // Явная зависимость
    }
}

// В тестах легко подменить
@Test
void test() {
    UserRepository mockRepo = mock(UserRepository.class);
    UserService service = new UserService(mockRepo);
    // Тестируем изолированно
}

---

🔴 Senior Level

Архитектурная деградация

Нарушение SOLID:

Принцип	Как Singleton нарушает
Single Responsibility	Класс управляет и логикой, и своим lifecycle
Open/Closed	Невозможно расширить без изменения
Liskov Substitution	Нельзя подменить наследником
Interface Segregation	Зависим от конкретной реализации
Dependency Inversion	Зависим от конкретики, не от абстракции

Static Initialization Deadlocks

// ❌ Взаимная зависимость в статических инициализаторах
public class A {
    static { B.getInstance(); }  // Ждёт B
    private static A instance = new A();
    public static A getInstance() { return instance; }
}

public class B {
    static { A.getInstance(); }  // Ждёт A
    private static B instance = new B();
    public static B getInstance() { return instance; }
}

// Thread 1: загружает A → ждёт B
// Thread 2: загружает B → ждёт A
// → DEADLOCK на этапе Class Loading!
// → Очень трудно отловить

Горизонтальное масштабирование

// Singleton бесполезен для распределённых ID
public class IdGenerator {
    private static long counter = 0;
    public static synchronized long nextId() { return ++counter; }
}

// В кластере из 5 нод:
// Node 1: 1, 2, 3
// Node 2: 1, 2, 3  ← Дубли!
// Node 3: 1, 2, 3

// ✅ Решение: распределённый генератор
// Redis INCR, Snowflake ID, UUID

Lifecycle Management

// ❌ Singleton не имеет shutdown()
public class ConnectionPool {
    private static ConnectionPool instance;
    private List<Connection> connections;
    
    private ConnectionPool() {
        connections = createConnections();  // Открыли 10 соединений
    }
    
    // Как закрыть при остановке приложения?
    // Нет стандартного метода!
}

// ✅ Spring: @PreDestroy
@Component
public class ConnectionPool {
    @PreDestroy
    public void shutdown() {
        connections.forEach(Connection::close);
    }
}

Thread Contention в Highload

// ❌ Mutable Singleton = bottleneck
public class MetricsCollector {
    private static MetricsCollector instance;
    private final Map<String, Long> metrics = new ConcurrentHashMap<>();
    
    public void increment(String name) {
        metrics.merge(name, 1L, Long::sum);  // ConcurrentHashMap, но...
    }
    
    public Map<String, Long> getMetrics() {
        return new HashMap<>(metrics);  // ...copy каждый раз!
    }
}

// При 10,000 req/sec:
// ConcurrentHashMap снижает contention, но copy в getMetrics() создаёт 10,000 объектов/сек → GC pressure.

// ✅ Решение: ThreadLocal или распределённые метрики

ClassLoader Memory Leaks Deep Dive

Tomcat redeploy:
1. Старый webapp ClassLoader должен быть GC
2. Но Singleton.class имеет static поле → ссылка
3. ClassLoader не может быть GC
4. Все классы webapp остаются в памяти
5. Metaspace растёт → OutOfMemoryError

// Решение: 
// 1. НЕ использовать static Singletons в webapp
// 2. Использовать DI контейнер (Spring)
// 3. Spring сам очищает при shutdown

Production Experience

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

• Rate Limiter как Singleton
• 5 нод в кластере
• Ожидали: 100 req/min на все ноды
• Реальность: 100 req/min НА КАЖДУЮ ноду (500 total!)
• Решение: Redis-based rate limiter

Реальный сценарий #2: Static deadlock в production

• Два Singleton инициализировали друг друга
• Deadlock при старте → приложение зависло
• 4 часа дебага → нашли через thread dump
• Решение: убрали циклическую зависимость

Реальный сценарий #3: Memory Leak

• Metaspace рос на 50 МБ при каждом deploy
• Через 10 deploy → OutOfMemoryError
• Причина: Singleton держал ClassLoader
• Решение: мигрировали на Spring DI

Best Practices

1. НЕ используйте ручные Singleton в Spring-приложениях
2. DI Container управляет lifecycle лучше
3. Избегайте мутабельного состояния в Singleton
4. Для кластера → распределённые решения (Redis, ZK)
5. Мониторьте Metaspace при использовании static

ZK (Zookeeper) — распределённая система координации.

1. @PreDestroy для корректного shutdown
2. ThreadLocal для снижения contention
3. Явные зависимости через конструктор

Резюме для Senior

• SOLID violations: Singleton нарушает 5 из 6 принципов
• Static deadlocks: трудно отловить, катастрофично
• ClassLoader leaks: Metaspace OOM при redeploy
• Cluster myth: Singleton ≠ distributed uniqueness
• Thread contention: mutable state = bottleneck
• Lifecycle: нет стандартного shutdown механизма
• DI Container решает ВСЕ эти проблемы
• Правило: Singleton только для stateless утилит или SDK

---

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

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

• Singleton нарушает SOLID: SRP (управление lifecycle), DIP (скрытые зависимости), OCP (невозможно расширить), LSP (нельзя подменить), ISP (зависимость от конкретики)
• Невозможно тестировать: нельзя замокать, состояние между тестами → flaky tests
• Static initialization deadlocks — два Singleton инициализируют друг друга → deadlock при старте
• ClassLoader memory leaks: в Tomcat при redeploy Singleton мешает GC → Metaspace OOM
• В кластере Singleton бесполезен — каждая нода создаёт свой экземпляр
• Мутабельное состояние в Singleton = thread contention bottleneck
• DI Container решает ВСЕ эти проблемы

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

• Какие принципы SOLID нарушает Singleton? — SRP (двойная ответственность), DIP (скрытые зависимости), OCP (нельзя расширить), LSP (нельзя подменить)
• Что такое static initialization deadlock? — Два класса в статических блоках ждут друг друга → deadlock на этапе Class Loading
• Почему Singleton течёт в Tomcat? — Static поле держит ClassLoader → ClassLoader не GC → Metaspace растёт
• Как решить проблему тестируемости? — DI: передача зависимостей через конструктор вместо Singleton.getInstance()

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

• “Singleton отлично тестируется” — невозможно замокать, состояние между тестами
• “Я не использую DI, Singleton проще” — скрытые зависимости = technical debt
• “В кластере Singleton решает проблему координации” — каждая нода создаёт свой экземпляр
• “Static deadlocks невозможны” — возможны при циклической зависимости статических инициализаторов

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

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