Потокобезопасный singleton

Question

Вот потокобезопасный singleton:

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

Никак не пойму зачем ему volatile, если он и так лочится по Singleton.class. От чего это спасает ?

http://ru.stackoverflow.com/questions/1271/%D0%9A%D0%BB%D1%8E%D1%87%D0%B5%D0%B2%D0%BE%D0%B5-%D1%81%D0%BB%D0%BE%D0%B2%D0%BE-volatile-%D0%B2-java — arkadij_ok, Nov 14 '16 at 18:49
@arkadij_ok я знаю, что такое volatile и даже знаю про кэш процессора. Вопрос в том, зачем нам делать instance защищенным от кеширования, если вторая проверка происходит внутри залоченного монитора ? — faoxis, Nov 14 '16 at 19:03
Не знал что можно синхронизировать по Object.class — Arch, Nov 15 '16 at 07:58

score 14 · Accepted Answer · edited Jun 12 '20 at 12:52

Операция создания объекта в Java не является атомарной.

Рассмотрим (один из возможных) пример с выполнением операции создания объекта и двумя потоками:

Поток A входит в метод getInstance(), в этот момент времени instance == null и он входит в синхронизированный блок, в котором тоже instance == null и начинает создание объекта Singleton. Сначала выделяется память под объект, потом этот объект инициализируется ссылкой на выделенную область памяти. В этот момент времени Поток B заходит в метод getInstance() видит, что instance != null и начинает использовать уже существующий, но еще не донца сконструированный объект (так как его поля еще не инициализированы).

Объявление поля instance как volatile (JDK 5+) устанавливает отношение happens before между инициализацией объекта instance Потоком A и возвратом объекта instance Потоку B.

Иными словами, объявление поля instance как volatile гарантирует, что поток В прочитает уже полностью сконструированный объект instance.

UPD. Из комментариев @Roman еще одна причина необходимости использования volatile:

Без volatile есть ещё одна проблема: если первая проверка if (instance == null) увидит не null, последующий return instance может увидеть null, в результате метод вернёт null.

Если нет корректной синхронизации, то чтение, которое идёт "позже" может увидеть значение, которое было "раньше", т.к. JMM не запрещает переупорядочивать такие чтения.

Переменная, объявленная volatile, никогда не кешируется в память потока, то есть она в любой момент времени в любом потоке будет иметь одинаковое (актуальное) значение (если один поток меняет ее значение, то это значение сразу же доступно в других потоках).

Без volatile есть ещё одна проблема: если первая проверка if (instance == null) увидит не null, последующий return instance может увидеть null, в результате метод вернёт null. — Roman, Nov 14 '16 at 23:33
@Roman, А как в данной реализации можно обнулить instance? — post_zeew, Nov 15 '16 at 00:15
Никто и не обнуляет instance. Просто если нет корректной синхронизации, то чтение, которое идёт "позже" может увидеть значение, которое было "раньше", т.к. JMM не запрещает переупорядочивать такие чтения. См. простой пример и пример из вопроса (Unsafe DCL + Safe Singleton). — Roman, Nov 15 '16 at 02:22

score 0 · Answer 2 · answered Nov 14 '16 at 19:55

Потому что чтение при сравнении

if (instance == null) {

происходит вне synchronized блока, а так уже и sideeffects могут быть, например, созданный объект в heap, но с ещё не вызванным конструктором или кешированное значение null. Модель памяти JDK 5.0 и выше требует этого, чтобы поведение многопоточных программ было предсказуемым.

сравнение происходит дважды – faoxis Nov 14 '16 at 20:20 — faoxis, Nov 14 '16 at 20:20

Потокобезопасный singleton

2 Answers2