Basil A. SidorovЛично я не стал бы полагаться на это поведение.
Volatile даёт определённые гарантии относительно конкретной переменной.
Ладушки, а всё остальное - от лукавого.Сила volatile как раз и строится на piggibacking:
int x = 0;
volatile int y = 0;

Thread1:
x = 1;
y = 1;

Thread2:
if (y == 1)
assert x == 1;

Это очень мощная фича, которая очень широко применяют в конкурентном программировании. Ничего в ней "лукавого" нет.

Basil A. SidorovИ, типа, от порядка объявления-следования ничего не зависит? Совсем-совсем?Не понял вопрос.

redwhite90а можете по каждому пункту предоставить прувы, а то смотрю мнения расходятся.Ну давайте для большей точности вот так скажем:

1) Не будет сохранять ее в регистрах
2) Не будет оптимизировать код вокруг нее (не будет выпиливать ее чтения, не будет ее переставлять и т.д.)
3) Вокруг ее чтения/записи компилятор добавить специальных инструкций процессора, которые почистят store buffer / invalidate queue кэшей. Обычно это делают через вызов системных функций операционной системы, которая в свою очередь исполнит нужные инструкции процессора.

Ибо п.1 - это по сути одна из оптимизаций из п.2. Здесь принципиально то, что каждое чтение волатильной переменной должно сопровождаться ее реальным чтением из подсистемы "кэш-память". А сохраняет ее процессор для каких-то своих нужд в регистры или нет - дело третье. Хочет сохранить - ну пускай сохранит.
Например, предположим, что у нас есть следующий код:



И вы вызываете method1(). Как будет выглядеть assembly? Может быть так:



А может быть вот так:


// Вызвали метод.

Первый способ - стандартный, специфицированный подход к вызову функций.
Второй способ - более быстрая вариация, так называемый fastcall, так как быстрее сохранить переменную в регистр, чем записывать ее в стэк.
Но в обоих случаях была создана копия волатильной переменной. Это страшно? Нет, ведь мы передаем int в метод, а примитивы передаются в методы по значению. То есть у нас просто напросто нет другого варианта, кроме как скопировать волатильную переменную.

Но если бы переменная не была волатильной, то во втором случае JVM могла бы попробовать переиспользовать ее из регистра при последующем чтении. А если она волатильна, то такого переиспользования не будет.

Так что не циклитесь на регистрах. Это детали.

questionerговорят, что понять как работает волатайл можно по следующему коду
http://hg.openjdk.java.net/icedtea/jdk7/hotspot/file/d9f0ed25f7ed/src/share/vm/opto/memnode.cpp#l2862
кто знает ассемблер -расскажите что там написано)Это кишки компилятора, они вам никак не помогут понять volatile.

Basil A. SidorovПереставили местами порядок объявления переменных, порядок следования операторов в тексте программы.
Есть класс с кучей переменных. Если одна единственная volatile выключит оптимизацию всего остального, то не пошло бы оно лесом - такое поведение?
На каком фрагменте действует volatile?volatile не выключает "все остальное". Она синхронизирует состояние в момент ее чтения/записи. До/после этого можно оптимизировать все, что угодно.

Basil A. Sidorov
Пример идиотский, но суть проблемы, думаю понятна: изменчивость - плохой барьер.Ну так давайте будем рассматривать какой-нибудь "хороший" пример, который действительно можно использовать на практике.

Вашей претензией является неочевидность. С этим никто и не спорит. Но с другой стороны, никто и не говорит, что этот подход надо использовать в регулярной практике. Piggibacking часто применяют в замысловатых неблокирующих алгоритмах, когда хотят максимально расслабить синхронизацию, и т.д.. Рядовой программист, который может бездумно "переставить две строчки" в такой код не полезет.
Для сложных задач - сложный код, для простых - простой.

Basil A. SidorovЗачем обсуждать (реально) тёмные детали устройства процессора, если всё, что достаточно знать об изменчивости, укладывается вот в это предложение:Fixing the Java Memory ModelThis process guarantees that when a variable is written by one thread during a synchronized block protected by a given monitor and read by another thread during a synchronized block protected by the same monitor, the write to the variable will be visible by the reading thread?
Т.е. раньше гарантии видимости распространялись только на саму переменную, теперь - на все предыдущие присваивания. Что улучшает синхронизацию, за счёт незначительной просадки производительности.Всего существует два "типа синхронизации":
1) Release semantics - после записи некоторой переменной она становится потенциально видна другим потокам, так же, как и все записи, которые шли до нее.
2) Acquire semantics - после чтения некоторой переменной, все последующие чтения других переменных должны вычитать более новые значения "себя".

Все, другого не дано. Предложение, которое вы привели описывает только synchronized. А работает он так:
acquire()
тело_synzcronized_блока
release()

volatile работает вот так:
запись_volatile_переменной
release()

acquire()
чтение_volatile_переменной

Соответственно, все те трюки с piggibacking, которые возможны с volatile, возможны и с synchronized. Вот это работает:


Thread 2:



Что бы не верить на слово, что оно работает именно так, а понимать почему оно именно так было спроектировано и именно так работает, и надо знать и про JIT, и про store buffer / invalidate queue. Это улучшает понимание протекающих процессов, а от этого еще никому хуже не стало.

Basil A. SidorovОднопоточная семантика осталась прежней, многопоточная - разрушена.Ничего не разрушено ... так как в вашем примере многопоточная семантика изначально была некорректной. Нечего разрушать. Предлагаю оставить этот бессмысленный пример, и рассматривать что-то реально применимое.