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

SZ>Здравствуйте, bolshik, Вы писали:

B>>Здравствуйте, mik1, Вы писали:

M>>>Посмотрите внимательно на то, как поля инициализированы в конструкторе, и на то, в каком порядке их устанавливает setter. Речь идет именно о переупорядочивании операций.
B>>правильно ли я понимаю, что ты имеешь ввиду, что когда в setter() сначала инициализируется int, потом boolean, авторы считают, что этот порядок противоположен? С моей точки зрения там беда в том, что поля объявлены без модификатора volatile.

SZ>На этом примере автор хотел показать что — "There is no guarantee that operations in one thread will be performed in the order given by the program." Это называется 'reordering'.
SZ>Присваивание boolean переменной могло происходить раньше чем int (например из-за оптимизации компилятором). И другой поток мог увидеть boolean раньше и получить неверное значение int.
SZ>По спецификации JVM (а точнее её части Java Memory Model) volatile не помогала в таких случаях до версии JVM 5.0, ещё в версии 1.4 volatile переменные могли реордерится (http://www-128.ibm.com/developerworks/java/library/j-jtp02244.html — Problem 2) хотя для 1.4 вышла заплатка в виде багфикса, которая меняла это поведение и запрещала реордеринг volatile переменных.

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