Кратко и по существу.
Почему в старых версиях Java (до Java $5$) DCL был некорректен
- Проблема — модель памяти (JMM) до JSR‑133 позволяла перестановки и не гарантировала видимость записей между потоками. Создание объекта фактически может выполняться в трёх логических шагах: $1$ — выделить память, $2$ — инициализировать объект, $3$ — записать ссылку в поле. Без специальных гарантий шаги могут быть переупорядочены (например, $1,3,2$). В результате другой поток может прочитать ненулевую ссылку и получить ссылку на ещё не полностью инициализированный объект (поля — дефолтные значения) — баги, в том числе приводящие к некорректному поведению или NPE.
- Также без volatile запись одного потока может не стать видимой другому вовремя (кэширование и отсутствие happens‑before).
Как правильно реализовать потокобезопасную ленивую инициализацию
1) Простое исправление DCL (корректно с Java $5$ и выше):
- Объявить поле volatile:
private static volatile MyObj instance;
public static MyObj get() {
MyObj result = instance;
if (result == null) {
synchronized (MyClass.class) {
if (instance == null) instance = new MyObj();
result = instance;
}
}
return result;
}
- volatile предотвращает переупорядочивание и обеспечивает видимость; локальная переменная сокращает число обращений к volatile.
2) Надёжная и простая альтернатива — инициализатор на требование (holder idiom):
private static class Holder { static final MyObj INSTANCE = new MyObj(); }
public static MyObj get() { return Holder.INSTANCE; }
- Класс Holder инициализируется JVM лениво и потокобезопасно (гарантии загрузчика классов).
3) Другие варианты:
- synchronized метод: public static synchronized MyObj get() { if (instance==null) instance=new MyObj(); return instance; } — проще, но синхронизация на каждом вызове.
- enum‑singleton или фабрики — для одиночек.
Итого: до Java $5$ DCL был небезопасен из‑за reorder/видимости; начиная с Java $5$ корректный DCL требует volatile либо используйте holder idiom/enum/synchronized.