Как сделать Singleton потокобезопасным

Как сделать Singleton потокобезопасным

Проблема: не потокобезопасный Singleton

Наивная реализация Singleton может привести к созданию нескольких экземпляров в многопоточном окружении:

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

Проблема: race condition между проверкой и созданием. Два потока могут одновременно пройти проверку if (instance == null) и оба создадут экземпляры.

Решение 1: Synchronized метод (простое, но медленное)

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {}
    
    // Синхронизируем весь метод
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Плюсы:

• Просто и понятно
• Гарантирует только один экземпляр

Минусы:

• Каждый вызов getInstance() требует синхронизацию (блокировка)
• Пропускная способность падает в многопоточной системе

Решение 2: Double-Checked Locking (оптимальное для Java)

Это самый популярный способ:

public class Singleton {
    private static volatile Singleton instance;
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        // Первая проверка (без блокировки)
        if (instance == null) {
            synchronized (Singleton.class) {  // Синхронизируем блок
                // Вторая проверка (с блокировкой)
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Почему volatile?

Ключевое слово volatile гарантирует, что:

1. Изменения видны всем потокам немедленно
2. Инструкции не переупорядочиваются (happens-before)
3. Без volatile один поток может видеть частично инициализированный объект

Плюсы:

• Синхронизация только при первом создании
• После создания экземпляра синхронизация не требуется
• Хороший баланс между производительностью и безопасностью

Минусы:

• Более сложный код
• Нужно понимать volatile

Решение 3: Eager Initialization (инициализация при загрузке класса)

public class Singleton {
    // Экземпляр создается при загрузке класса
    private static final Singleton instance = new Singleton();
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        return instance;
    }
}

Плюсы:

• Потокобезопасно по умолчанию (гарантия JVM)
• Простой код
• Отсутствует синхронизация при доступе

Минусы:

• Экземпляр создается всегда, даже если не используется
• Нет ленивой инициализации

Решение 4: Bill Pugh Singleton (лучший подход на практике)

Использует статический инициализатор (helper class):

public class Singleton {
    private Singleton() {}
    
    // Статический внутренний класс
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
    
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

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

1. Класс SingletonHolder не загружается при загрузке Singleton
2. INSTANCE создается только при первом обращении к getInstance()
3. JVM гарантирует потокобезопасность инициализации класса

Плюсы:

• Ленивая инициализация
• Потокобезопасно без synchronized
• Чистый и элегантный код
• Отличная производительность

Минусы:

• Требует понимания класслоадинга

Решение 5: Enum Singleton (самый безопасный)

public enum Singleton {
    INSTANCE;
    
    // Методы Singleton
    public void doSomething() {
        System.out.println("Singleton работает");
    }
}

// Использование
Singleton.INSTANCE.doSomething();

Плюсы:

• Потокобезопасно (по контракту Java enum)
• Защищен от рефлексии
• Защищен от сериализации/десериализации
• Очень простой код

Минусы:

• Может быть неудобен для наследования
• Не очень понятен для новичков

Решение 6: Сравнительная таблица

Полный пример с тестированием

public class Singleton {
    private static volatile Singleton instance;
    private String data = "Singleton data";
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
    
    public String getData() {
        return data;
    }
}

// Тестирование в многопоточной среде
public class SingletonTest {
    public static void main(String[] args) throws InterruptedException {
        Set<Singleton> instances = Collections.synchronizedSet(new HashSet<>());
        
        // 100 потоков пытаются получить экземпляр
        Thread[] threads = new Thread[100];
        for (int i = 0; i < 100; i++) {
            threads[i] = new Thread(() -> {
                instances.add(Singleton.getInstance());
            });
        }
        
        // Запускаем все потоки
        for (Thread thread : threads) {
            thread.start();
        }
        
        // Ждем завершения
        for (Thread thread : threads) {
            thread.join();
        }
        
        // Проверяем, создался только один экземпляр
        System.out.println("Количество экземпляров: " + instances.size());
        assert instances.size() == 1 : "Singleton не потокобезопасен!";
        System.out.println("Все экземпляры одинаковые: Singleton потокобезопасен!");
    }
}

Рекомендации по выбору

1. Для 99% случаев: используйте Bill Pugh (статический инициализатор)

   • Ленивая инициализация
   • Нет synchronized
   • Чистый код

2. Если нужна максимальная безопасность: используйте Enum Singleton

   • Защита от рефлексии
   • Защита от сериализации
   • Гарантированная потокобезопасность

3. Если нужна ленивая инициализация и простота: используйте Double-Checked Locking

   • Но убедитесь, что используете volatile

4. Избегайте:

   • Простого synchronized (низкая производительность)
   • Наивной реализации без синхронизации