Java for Beginner

[Совет по Java #034]

Тема: Ленивая инициализация синглтона через double-checked locking требует volatile.

Проблема: Паттерн double-checked locking (DCL) предназначен для ленивой инициализации синглтона с минимальной синхронизацией.

Классическая реализация без volatile содержит скрытую гонку данных из-за переупорядочивания инструкций (instruction reordering). Процесс создания объекта включает три этапа: выделение памяти, инициализация полей, присвоение ссылки переменной.

Компилятор и процессор могут переставить инициализацию и запись ссылки. В результате один поток может увидеть ненулевой, но еще не проинициализированный объект (partially constructed object), что приведет к непредсказуемому поведению, NullPointerException или чтению значений по умолчанию вместо заданных конструктором. Без volatile JVM не гарантирует happens-before связи между записью и последующим чтением.

Решение: Объявите поле синглтона как private static volatile. Модификатор volatile запрещает переупорядочивание операций с этим полем, обеспечивая, что запись ссылки произойдет только после полной инициализации объекта.

Начиная с Java 5 (и нового memory model), volatile обеспечивает правильный DCL.

Альтернативы: инициализация при загрузке класса (eager initialization) или использование enum-синглтона. Для современных проектов предпочтительнее подход с внутренним статическим классом (Initialization-on-demand holder idiom), который не требует ручной синхронизации.

public class Singleton {
    
    //Антипаттерн: double-checked locking без volatile
    private static Singleton instance; // отсутствует volatile!
    
    public static Singleton getInstanceBad() {
        if (instance == null) { // Первая проверка
            synchronized (Singleton.class) {
                if (instance == null) { // Вторая проверка
                    instance = new Singleton(); // Может быть переупорядочено!
                }
            }
        }
        return instance;
    }
    
    //Решение: volatile гарантирует корректность
    private static volatile Singleton instance;
    
    public static Singleton getInstanceGood() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // Теперь безопасно
                }
            }
        }
        return instance;
    }
    
    //Лучшее решение без синхронизации: Initialization-on-demand holder
    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }
    
    public static Singleton getInstanceHolder() {
        return Holder.INSTANCE; // Инициализация при первом обращении
    }
    
    //enum-синглтон (сериализация безопасна)
    public enum EnumSingleton {
        INSTANCE;
        public void doSomething() { }
    }
    
    private Singleton() { }
}

Объяснение: Проблема DCL без volatile связана с тем, что запись ссылки instance = new Singleton() неатомарна.

Без volatile возможен следующий сценарий: поток A выполняет выделение памяти, записывает ссылку в instance, но инициализация конструктора еще не завершена. Поток B входит в метод, видит instance != null и возвращает недосозданный объект. volatile создает барьер памяти (memory barrier), который запрещает переупорядочивание и гарантирует, что все записи до момента присвоения будут видны всем потокам после.

В Java 5+ спецификация memory model была усилена, и DCL с volatile работает корректно. Однако идиома holder-класса предпочтительнее: она использует механизм потокобезопасной инициализации классов JVM, не требует явной синхронизации и короче.

#Java #советы

👍6

109 views08:59