no56892Кстати я так подумал, а действительно может сначало не null вернуть, а затем return null. Например, вот так: поток проверяет instance == null и это false (ну каким то чудом в кэше этого ядра оказалось достоверное значение), затем саспендится и планировщиком перекидывается на другое ядро, в чьем кэше старое значение, т.е. null, а так как это обычное чтение без синхронизации, то оно и возвращается.

А вот вариант:


эту проблему решает без волатайл. Кстати, тут еще одна штука зачем нужен волатайл - если конструктор у Синглтона "не safe", то это делает возможным получение ссылки на не доконца инициализированный объект, код Выше эту проблему тоже не решает. Так что вот реально, вроде дошло)) Правда у меня еще есть как-бы все говорят про перестановки и т.д., дак что мешает компилятору выкинуть эту локальную переменную вообще? Или так не делается? Вот этот момент не понятен остался только.

Думаю правда, но не это главная проблема DCL. Нашёл ответ в concurrency in practice:
concurency in practisethe real problem with DCL is the assumption that the worst thing that can happen when reading the shared object reference without synchronization is to erroneously see a stale value (in this case, null); in that cse the DCL idiom compensates for this risk by trying again with the lock held. But the worst case is actually considerably wrong - it is possible to see a current value of the reference but stale values for the object's states, meaning that the object could be seen to be in an invalid or incorrect state.


В итоге получаем, что если на момент публикации volatile переменной в объекте были выставлены поля, то мы как минимум на этот момент их увидим. Но если мы сначала присвоили volatile, а потом начали менять состояние объекта, на который указывает ссылка( выставлять поля), то гарантий нет.


Что же касается final, то как я и думал магический freeze action всё сделает за нас.





в книге приведен в точности до имен пример как пример безопасной публикации.

Наконец-то разобрался)