Сергей АрсеньевЧто sync, что volatile, что atomic с точки зрения JMM ставят барьер (грань happens before) и jvm должна гарантировать, что изменения сделанные в потоке A до этого барьера (записи ссылки) должны быть видны в потоке B после этого барьера (чтения ссылки).

IMHO Первая часть Вашего ответа, противоречит второй.

IMHO & AFAIK. Volatile гарантирует, что данная _атомарная_ переменная/ссылка, будет корректна видна. Но не гарантирует, что другие данные будут корректно видны. Т.е. такой себе "мини-барьер" который нисколько гонкам по другим данным не препятствует.

Сергей Арсеньев
Однако, если ссылка остается прежней, а меняется содержимое, то в потоке B нельзя гарантировать, что он не прочел старое значение ссылки (то же самое) и потому барьер на него может не распространяться.
А можно как-то JVM "более легким" образом (чем syncronized) сказать, что нужен барьер распространяющийся на все действия которые были проведены внутри потока (т.е. выкинуть данные объекта и всего остального дерева объектов которые внутри него)?

Использовать synchronized в качестве барьера, когда мне реального Lock'а не требуется, достаточно "сурово". Использовать Lock, когда опять таки, мне лока не требуется так же. IMHO

Сергей АрсеньевLeonid Kudryavtsev[
IMHO & AFAIK. Volatile гарантирует, что данная _атомарная_ переменная/ссылка, будет корректна видна. Но не гарантирует, что другие данные будут корректно видны. Т.е. такой себе "мини-барьер" который нисколько гонкам по другим данным не препятствует.

Еще раз по шагам.
Грань h-b выставляемая записью в volatile позволит после чтения правильно прочитать то, что было до записи volatile. Если объект, на который указывает ссылка, не менялся после записи volatile. Если менялся - то никаких гарантий. Или если другой поток получил ссылку не через volatile.

То есть, все данные внутри экземпляра объекта, в том числе, если поля внутри объекта не объявлены как "volatile" ?

Пока на практике наблюдаю другое. Создаю объект, помещаю в AtomicReference (тот же volatile) потом про данный объект забывает, другой поток забирает из AtomicReference, периодически объект приходит не консистентным.

Ошибка в моем коде не исключена. Т.ч. могу быть не прав. Но пока складывалось чувство, что volatile & AtomicReference не гарантирует консистентнось данных внутри помещенного туда экземпляра.