Коротко — приведённый код небезопасен, потому что доступ к `instance` не синхронизирован и нет гарантий видимости/порядка записей в памяти по модели Java Memory Model (JMM). Ниже — почему, как это проявляется и как это исправить.
Почему это небезопасно (JMM):
- Обращение `if (instance == null)` и запись `instance = new S()` выполняются без синхронизации → data race. При наличии гонки JMM не гарантирует happens‑before между записью и чтением, поэтому разные потоки могут видеть разные значения и видеть их в разном порядке.
- Конструкция `new S()` концептуально разбивается на шаги: выделение памяти → инициализация объекта (выполнение конструктора) → присвоение ссылки полю `instance`. JVM/компилятор/процессор могут переставить эти шаги (реалистично: присвоение ссылки может стать видимым другому потоку до полной инициализации объекта). Это приводит к «публикации частично сконструированного объекта».
- Наличие полей с модификатором `final` частично смягчает проблемы видимости для этих полей, но НЕ решает проблему присвоения ссылки `instance` без синхронизации.
Возможные проявления ошибок:
- Два (или больше) потока одновременно увидят `instance == null` и создадут разные объекты — нарушение семантики singleton.
- Поток A создаёт объект, ссылка записана в `instance`, но конструктор ещё не завершён; поток B видит ненулевую ссылку и использует объект с неинициализированными/дефолтными полями → неправильное поведение, исключения (например, NPE) или некорректные данные.
- Непредсказуемые редкие баги, зависящие от архитектуры/оптимизаций — трудно отлавливать.
Корректные и эффективные способы реализации ленивой потокобезопасной инициализации
1) Инициализация при загрузке (не лениво, но просто и безопасно)
public class S {
private static final S INSTANCE = new S();
public static S get() { return INSTANCE; }
}
Плюсы: простая, потокобезопасная. Минусы: экземпляр создаётся при загрузке класса (не лениво).
2) Синхронизованный метод (лениво, корректно)
public class S {
private static S instance;
public static synchronized S get() {
if (instance == null) instance = new S();
return instance;
}
}
Плюсы: просто и правильно. Минусы: синхронизация при каждом вызове (в JVM современные реализации делают это дешёвой, но всё равно overhead).
3) Double-checked locking с volatile (лениво, эффективно)
public class S {
private static volatile S instance;
public static S get() {
S result = instance; // локальная переменная для оптимизации
if (result == null) {
synchronized (S.class) {
result = instance;
if (result == null) instance = result = new S();
}
}
return result;
}
}
Важно: поле должно быть объявлено `volatile`. Начиная с Java 5 DCL с `volatile` корректен. Плюсы: минимальная синхронизация. Минусы: чуть более сложен.
4) Initialization-on-demand holder (рекомендуемый паттерн: лениво и эффективно)
public class S {
private S() {}
private static class Holder {
static final S INSTANCE = new S();
}
public static S get() { return Holder.INSTANCE; }
}
Плюсы: лениво, прост, полностью потокобезопасно благодаря семантике инициализации класса (ClassLoader synchronization). Часто лучший выбор.
5) Enum singleton (простой, безопасный, предотвращает некоторые проблемы с сериализацией)
public enum S {
INSTANCE;
// методы
public static S get() { return INSTANCE; } // необязательно
}
Плюсы: гарантированная корректность, простота. Минусы: немного иная форма (но часто предпочтительна).
6) Использовать java.util.concurrent (например, AtomicReference + CAS) — вариант для специализированных случаев:
private static final AtomicReference ref = new AtomicReference();
public static S get() {
S cur = ref.get();
if (cur == null) {
S newS = new S();
if (ref.compareAndSet(null, newS)) return newS;
else return ref.get();
}
return cur;
}
Рекомендация:
- Если нужна простота и ленивость — используйте Holder idiom (пункт 4) или enum (если форма допустима).
- Если требуете строго ленивую и минимальную синхронизацию — DCL с `volatile` (пункт 3).
- Если не важна ленивость — используйте `private static final` (пункт 1).
- Никогда не оставляйте неблокированную проверку `if (instance == null)` без дополнительных механизмов видимости/синхронизации, это приводит к data race и возможной публикации частично сконструированного объекта.