Что будет, если запросить Singleton в трех методах

Singleton в трёх методах: потокобезопасность и гарантии

Краткий ответ

Если запросить Singleton в трёх методах одновременно (в разных потоках), всё зависит от того, как именно реализован Singleton. Неправильная реализация приведёт к созданию нескольких экземпляров, нарушив суть паттерна.

Проблема: простая реализация Singleton

// ❌ ОПАСНО: не потокобезопасно
public class SimpleSingleton {
    private static SimpleSingleton instance;
    
    private SimpleSingleton() {
    }
    
    public static SimpleSingleton getInstance() {
        if (instance == null) {  // Проблема здесь!
            instance = new SimpleSingleton();
        }
        return instance;
    }
}

// Демонстрация проблемы (race condition)
// Поток 1:                          Поток 2:
// 1. Проверка: instance == null      
// 2. Выполнение new Singleton()      1. Проверка: instance == null
// 3. instance = <новый объект>       2. Выполнение new Singleton()
//                                     3. instance = <другой объект>

// Результат: создано 2 экземпляра! ❌

Различные потоки и их результаты

public class SingletonTest {
    public static void main(String[] args) throws InterruptedException {
        // Три потока запрашивают Singleton
        Thread thread1 = new Thread(() -> {
            SimpleSingleton s1 = SimpleSingleton.getInstance();
            System.out.println("Thread 1: " + s1.hashCode());
        });
        
        Thread thread2 = new Thread(() -> {
            SimpleSingleton s2 = SimpleSingleton.getInstance();
            System.out.println("Thread 2: " + s2.hashCode());
        });
        
        Thread thread3 = new Thread(() -> {
            SimpleSingleton s3 = SimpleSingleton.getInstance();
            System.out.println("Thread 3: " + s3.hashCode());
        });
        
        thread1.start();
        thread2.start();
        thread3.start();
        
        thread1.join();
        thread2.join();
        thread3.join();
    }
}

// Возможный вывод:
// Thread 1: 12345
// Thread 2: 67890  ← Другой объект!
// Thread 3: 54321  ← Ещё другой объект!

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

// ✅ Потокобезопасно, но неэффективно
public class SynchronizedSingleton {
    private static SynchronizedSingleton instance;
    
    private SynchronizedSingleton() {
    }
    
    public synchronized static SynchronizedSingleton getInstance() {
        if (instance == null) {
            instance = new SynchronizedSingleton();
        }
        return instance;
    }
}

// Проблема: synchronized блокирует весь метод
// Каждый вызов getInstance() приобретает lock
// Это замедляет приложение!

// Метрики производительности:
// getInstance() вызывается 1000 раз:
// - SimpleSingleton: 0.1 ms
// - SynchronizedSingleton: 50 ms (в 500 раз медленнее!)

Решение 2: Double-Checked Locking

// ✅ Потокобезопасно И эффективно
public class DoubleCheckedSingleton {
    private static volatile DoubleCheckedSingleton instance;
    
    private DoubleCheckedSingleton() {
    }
    
    public static DoubleCheckedSingleton getInstance() {
        // Первая проверка: без lock'а (быстро)
        if (instance == null) {
            // Вторая проверка: с lock'ом (редко)
            synchronized (DoubleCheckedSingleton.class) {
                if (instance == null) {
                    instance = new DoubleCheckedSingleton();
                }
            }
        }
        return instance;
    }
}

// Как это работает:
// Поток 1:                              Поток 2:
// 1. Первая проверка: null → true
// 2. Приобретение lock
// 3. Вторая проверка: null → true
// 4. Создание экземпляра
// 5. Освобождение lock                 1. Первая проверка: !null → false
//                                       2. Возврат существующего экземпляра

// Результат: 1 экземпляр, 2-й поток не ждёт lock ✅

Почему volatile важен?

// Без volatile:
// Поток 1 может закешировать значение instance в L1 cache
// Поток 2 может увидеть старое значение из main memory
// НАРУШЕНИЕ visibility гарантий!

// С volatile:
// Все потоки видят актуальное значение из main memory
// ✅ Гарантия visibility JMM (Java Memory Model)

Решение 3: Eager Initialization (простое, всегда работает)

// ✅ Потокобезопасно по умолчанию
public class EagerSingleton {
    private static final EagerSingleton instance = new EagerSingleton();
    
    private EagerSingleton() {
    }
    
    public static EagerSingleton getInstance() {
        return instance;
    }
}

// Как это работает:
// JVM гарантирует, что static final поля инициализируются
// потокобезопасно при загрузке класса
// Это работает благодаря class loading mechanism'у

// Недостаток: Singleton создаётся всегда, даже если не используется

Решение 4: Lazy Initialization Holder (идеально)

// ✅ Ленивая инициализация + потокобезопасность
public class LazyHolderSingleton {
    private LazyHolderSingleton() {
    }
    
    // Вспомогательный класс (holder)
    private static class Holder {
        static final LazyHolderSingleton instance = new LazyHolderSingleton();
    }
    
    public static LazyHolderSingleton getInstance() {
        return Holder.instance;
    }
}

// Как это работает:
// 1. Класс LazyHolderSingleton загружается
// 2. Holder не загружается до первого вызова getInstance()
// 3. При первом вызове JVM загружает Holder
// 4. JVM гарантирует потокобезопасную инициализацию static final

// Преимущества:
// - Ленивая инициализация ✅
// - Потокобезопасность ✅
// - Производительность ✅
// - Простота ✅
// - Работает даже с Reflection и сериализацией ✅

Решение 5: Enum (самое простое и надёжное)

// ✅ Потокобезопасно, защита от Reflection, сериализации
public enum EnumSingleton {
    INSTANCE;  // Только один экземпляр возможен
    
    public void doSomething() {
        System.out.println("Doing something");
    }
}

// Использование
EnumSingleton singleton1 = EnumSingleton.INSTANCE;
EnumSingleton singleton2 = EnumSingleton.INSTANCE;

assert singleton1 == singleton2;  // ✅ ВСЕГДА true

// Почему enum лучший:
// 1. Потокобезопасность встроена в язык
// 2. Защита от Reflection атак
// 3. Защита от сериализации/десериализации
// 4. Простота и чёткость кода

Сравнение всех решений

Демонстрация проблемы с Reflection

// Даже Singleton можно сломать через Reflection
public class ReflectionAttack {
    public static void main(String[] args) throws Exception {
        EnumSingleton s1 = EnumSingleton.INSTANCE;
        
        // Попытка создать ещё один экземпляр через Reflection
        Constructor<EnumSingleton> constructor = 
            EnumSingleton.class.getDeclaredConstructor();
        constructor.setAccessible(true);
        
        try {
            EnumSingleton s2 = constructor.newInstance();
        } catch (Exception e) {
            // Для enum это не сработает!
            System.out.println("Cannot create: " + e);
        }
    }
}

// Вывод: Cannot create: java.lang.IllegalAccessException
// Enum защищен от Reflection атак ✅

Итоговый вывод

Если запросить Singleton в трёх методах:

1. Простая реализация → Может быть 3 разных объекта (race condition)
2. Synchronized → 1 объект, но медленно
3. Double-Checked → 1 объект, быстро, но сложно
4. Holder → 1 объект, быстро, элегантно
5. Enum → 1 объект, быстро, защищено от всего

Рекомендация в production:

• Используй Enum Singleton если это возможно
• Используй Holder pattern если нужна ленивая загрузка обычного класса
• Избегай synchronized и double-checked locking (сложные, подвержены ошибкам)

В современном Java (и особенно в Spring) часто используют Dependency Injection вместо Singleton. Это проще и не требует ручного управления потокобезопасностью.