«1. Введение

В этом руководстве мы поговорим о шаблоне проектирования блокировки с двойной проверкой. Этот шаблон уменьшает количество захватов блокировки, просто предварительно проверяя условие блокировки. В результате этого обычно происходит повышение производительности.

Давайте подробнее рассмотрим, как это работает.

2. Реализация

Для начала рассмотрим простой синглтон с драконовской синхронизацией: 

public class DraconianSingleton {
    private static DraconianSingleton instance;
    public static synchronized DraconianSingleton getInstance() {
        if (instance == null) {
            instance = new DraconianSingleton();
        }
        return instance;
    }

    // private constructor and other methods ...
}

Несмотря на то, что этот класс является потокобезопасным, мы видим явный недостаток производительности: каждый раз, когда мы хотим чтобы получить экземпляр нашего синглтона, нам нужно получить потенциально ненужную блокировку.

Чтобы исправить это, мы могли бы начать с проверки необходимости создания объекта в первую очередь, и только в этом случае мы могли бы получить блокировку.

Идя дальше, мы хотим выполнить ту же самую проверку снова, как только мы войдем в синхронизированный блок, чтобы сохранить атомарность операции: 

public class DclSingleton {
    private static volatile DclSingleton instance;
    public static DclSingleton getInstance() {
        if (instance == null) {
            synchronized (DclSingleton .class) {
                if (instance == null) {
                    instance = new DclSingleton();
                }
            }
        }
        return instance;
    }

    // private constructor and other methods...
}

При использовании этого шаблона следует помнить, что поле должен быть изменчивым, чтобы предотвратить проблемы несогласованности кеша. На самом деле модель памяти Java допускает публикацию частично инициализированных объектов, что, в свою очередь, может привести к незаметным ошибкам.

3. Альтернативы

Несмотря на то, что блокировка с двойной проверкой потенциально может ускорить работу, у нее есть как минимум две проблемы:

    поскольку для правильной работы требуется ключевое слово volatile, она несовместима с Java 1.4 и более ранними версиями. версии это довольно многословно и затрудняет чтение кода

По этим причинам давайте рассмотрим некоторые другие варианты без этих недостатков. Все следующие методы делегируют задачу синхронизации JVM.

3.1. Ранняя инициализация

Самый простой способ обеспечить потокобезопасность — встроить создание объекта или использовать эквивалентный статический блок. Это использует тот факт, что статические поля и блоки инициализируются один за другим (Спецификация языка Java 12.4.2): 

public class EarlyInitSingleton {
    private static final EarlyInitSingleton INSTANCE = new EarlyInitSingleton();
    public static EarlyInitSingleton getInstance() {
        return INSTANCE;
    }
    
     // private constructor and other methods...
}

3.2. Инициализация по запросу

Кроме того, поскольку мы знаем из ссылки на спецификацию языка Java в предыдущем абзаце, что инициализация класса происходит при первом использовании одного из его методов или полей, мы можем использовать вложенный статический класс для реализации ленивой инициализации: 

public class InitOnDemandSingleton {
    private static class InstanceHolder {
        private static final InitOnDemandSingleton INSTANCE = new InitOnDemandSingleton();
    }
    public static InitOnDemandSingleton getInstance() {
        return InstanceHolder.INSTANCE;
    }

     // private constructor and other methods...
}

В этом случае класс InstanceHolder назначит поле при первом доступе к нему, вызвав getInstance.

3.3. Enum Singleton

Последнее решение взято из книги Джошуа Блока Effective Java (статья 3) и использует перечисление вместо класса. На момент написания этой статьи это считалось наиболее лаконичным и безопасным способом написания синглтона: его пределы и некоторые альтернативы. 

public enum EnumSingleton {
    INSTANCE;

    // other methods...
}

На практике излишняя многословность и отсутствие обратной совместимости делают этот шаблон подверженным ошибкам, поэтому его следует избегать. Вместо этого мы должны использовать альтернативу, позволяющую JVM выполнять синхронизацию.

Как всегда, код всех примеров доступен на GitHub.

«

As always, the code of all examples is available on GitHub.