Здравствуйте, Sergey.Zakharov, Вы писали:

SZ>Сорри, поторопился слегка На самом деле предыдущие виртуальные машины могли реордерить volatile и non-volatile (т.е. если int не volatile, а bool — volatile, тогда код не работает). Две volatile переменные запрещалось реордерить и раньше. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных. Т.е. после до присваивания чего-либо volatile переменной компилятор обязан сделать все присвоения non-volatile переменных. В новых VM (5.0), грубо говоря, запрещен также реордеринг volatile и non-volatile переменных.

Реордеринг volalile и не-volalile в некоторых случаях разрешен, а в некоторых нет.
Об этом проще прочитать в статье Doug Lea "The JSR-133 Cookbook for Compiler Writers" http://gee.cs.oswego.edu/dl/jmm/cookbook.html в главе 'Volatiles and Monitors'.

Вот выдержки из статьи:

"The main JMM rules for volatiles and monitors can be viewed as a matrix with cells indicating that 
you cannot reorder instructions associated with particular sequences of bytecodes. This table is not
 itself the JMM specification; it is just a useful way of viewing its main consequences for compilers
 and runtime systems.



------------------------------------------------------------------------------------------------
         Can Reorder          |                         2nd operation                           |
------------------------------------------------------------------------------------------------
        1st operation         |Normal Load/Store    |Vol Load/MonitorEnter|Vol Store/MonitorExit|
------------------------------------------------------------------------------------------------
Normal Load/Store             |                     |                     |         No          |
------------------------------------------------------------------------------------------------
Vol Load/MonitorEnter         |        No           |        No           |         No          |
------------------------------------------------------------------------------------------------
Vol Store/MonitorExit         |                     |        No           |         No          |
------------------------------------------------------------------------------------------------

Where:
    * Normal Loads are getfield, getstatic, array load of non-volatile fields
    * Normal Stores are putfield, putstatic, array store of non-volatile fields
    * Volatile Loads are getfield, getstatic of volatile fields that are accessible by multiple threads
    * Volatile Stores are putfield, putstatic of volatile fields that are accessible by multiple threads
    * MonitorEnters (including entry to synchronized methods) are for lock objects accessible by multiple threads.
    * MonitorExits (including exit from synchronized methods) are for lock objects accessible by multiple threads. 

The cells for Normal Loads are the same as for Normal Stores, those for Volatile Loads are the 
same as MonitorEnter, and those for Volatile Stores are same as MonitorExit, so they are collapsed 
together here (but are expanded out as needed in subsequent tables).

Any number of other operations might be present between the indicated 1st and 2nd operations in 
the table. So, for example, the "No" in cell [Normal Store, Volatile Store] says that a
 non-volatile store cannot be reordered with ANY subsequent volatile store; at least any that
can make a difference in multithreaded program semantics."