свеном,

если вы делаете
a = b+c+d
x = y+z

То эти две операции не зависят одна от другой, и проц может их выполнить одновременно, а jvm может переупорядочить. При этом вторая операция (условно) будет выполняется скорее чем первая. Таким образом вроде как получается, что они даже без переупорядочивания будут выполнены в обратном порядке. Как оно произойдет на практике - сказать нельзя, и может происходить по-разному от запуска к запуску.

пока вы делаете однопоточное приложение, это все вам без разницы и про это можно вообще не знать.

Но если вы из другого потока в это время юзаете значения "a" и "x", то внезапно может оказаться что x поменяется раньше, а вы на это не рассчитывали. Считаете что в "a" новое значение, но там все еще старое. То есть, из другого потока вообще порядок изменения переменных может выглядеть "перемешанным" относительно того, чего вам хотелось бы.

если вы делаете "a" и "x" волатильными, то их порядок, видимый из другого потока, приходит в норму. В данном случае - поменяется сначала "а" и только потом "х".

Тяжеловесная синхронизация - это делать запись и считывание внтри syncronized блока. В варианте с volatile "полегчает" время исполнения по сравнению с тяжеловесным случаем.

имеется в виду, что синхронизируется действительный порядок изменения с ожидаемым. При этом, в производительности вы немножко проигрываете.

Тяжелей волатиля схема "один писатель - много читателей", и еще тяжелей синхронизед.

ушел читать доки... docs.oracle.com/javase/specs/jvms/se5.0/html/Threads.doc.html#22258

а это не оно?:

забыл никLet action A be a use or assign by thread T on variable V, let action F be the load or store associated with A, and let action P be the read or write of V that corresponds to F. Similarly, let action B be a use or assign by thread T on variable W, let action G be the load or store associated with B, and let action Q be the read or write of W that corresponds to G. If A precedes B, then P must precede Q. (Less formally: operations on the master copies of volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested.)


непереводимая мешанина букв. И далее "менее формально: операции на мастер-копиях волатильных переменных выполняются в основной памяти, точном порядке, который прописан в потоке".


Насчет cas-а легко понять насколько он тяжел, зная как оно работает. - чтение и запись из памяти, с последующим сранением и зацикливанием. Фактически, он делает все то же, что делает волатил, плюс еще, возможно, несколько таких итераций. Причем, если несколько потоков это делают одновременно, то учасок памяти в котором хранится значение еще гуляет между кэшпамятью этих потоков (т.н. true sharing). Следовательно, cas немножко тяжелей volatile но легче "схемы один писатель-много читателей"

свеномволатильные сторы не реордеряться с любыми предыдущими сторами, даже с неволатильными.

Помоему, "даже с неволатильными" у synchronized, а у волатильных такого нету. Но этот момент надо тоже преверить.

свеном,

да, с этим замечанием я погорячился. Сорри.