schwaИ каким тут образом тогда в примере из стартового сообщения получается небезопасная публикация содержимого массива, если состояние коллабл, публикуется безопасно экзекутором?
Грубо говоря поле x объектов CallableClass будет ссылаться на тот же адрес в памяти, что и локальная переменная x в момент обращения к ней. Однако эта содержимое массива по этому адресу может еще только инициализироваться в основном потоке, когда новые потоки уже начнут к нему обращаться.

Безопасная публикация объектов CallableClass, означает что когда потоки задач смогут обратиться к объектам CallableClass - для этих объектов уже будет выполнен конструктор.

забыл ник_quark_,

Вы не правы в данном случае.

Рассмотрим по порядку -
1) идет инициализация массива и присваивание переменной ссылки на него
2) идет конструирование Callable в ТОМ же потоке, модель памяти java гарантирует что компилятор никак не должен ломать total execution of order внутри исполнения ОДНОГО потока, таким образом Callable будет гарантировано сконструирован правильно.
3) Далее мы ложим Callable в экзекьютор и экзекьютор сам уже заботится о публикации ссылки на Callable
Таким образом код абсолютно корректен. А вот если бы массив был параметром к методу, или полем класса - тогда да, возможны варианты, потому что непонятно в каком потоке он был создан.

Обратите внимание, что модель памяти Java гарантирует, что для одного потока код ведет себя так, словно выполняется последовательно. На самом деле порядок выполнения инструкций может изменяться (см. Java Concurrency in Practice Chapter 16. The Java Memory Model).
16.1. What is a Memory Model, and Why would I Want One?

...

The Java Language Specification requires the JVM to maintain within thread as if serial semantics: as long as the program has the same result as if it were executed in program order in a strictly sequential environment, all these games are permissible
Там же написано и то, зачем это делается.

1) может быть как раз наоборот: сначала в переменную будет записан указатель на адрес в памяти, а потом только массив будет проинициализирован
2) в поле x экземпляра Callable может быть записан указатель на тот же адрес в памяти, на который указывает локальная переменная x. При этом инициализация массива все-еще отложена (ведь экземпляр Callable в основном потоке к содержимому массива вообще не обращается)
3) экзекьютор безопасно публикует объект Callable - ссылка остается той же самой. То что он записывает в полю x экземпляра Callable тот же самый адрес, что содержит локальная переменная x, еще не означает, что массив уже должен быть проинициализирован - ведь к содержимому этого массива в основном потоке никто не обращается.

Итого в основном потоке инициализация массива может произойти например в самом конце метода main. В пределах основного потока - это допустимо, т.к. основной поток вообще не обращается к содержимому массива.
А потоки задач могут видеть массив непроинициализированным.

Если в конструкторе коллабл мы обращаемся к массиву, содержимое которого еще не инициализированно, то компилятор должен был преобразовать наш код в что-то следующее


А это некорректное преобразование, которое нарушает порядок выполнения программы - ведь инструкции, которые бы заполнили бы массив, были пропущены, а они должны были быть выполнены еще до завершения конструктора коллабл.[/quot]
Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
redwhite9000005
Смещение исключения: 000000000009970a
Версия ОС: 6.1.7601.2.1.0.256.1
Код языка: 1049
Дополнительные сведения 1: 4c0d
Дополнительные сведения 2: 4c0d4d78887f76d971d5d00f1f20a433
Дополнительные сведения 3: 4c0d
Дополнительные сведения 4: 4c0d4d78887f76d971d5d00f1f20a433

Неправильно процитировал.
schwaЕсли в конструкторе коллабл мы обращаемся к массиву, содержимое которого еще не инициализированно, то компилятор должен был преобразовать наш код в что-то следующее
...
А это некорректное преобразование, которое нарушает порядок выполнения программы - ведь инструкции, которые бы заполнили бы массив, были пропущены, а они должны были быть выполнены еще до завершения конструктора коллабл.

Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
redwhite9000005
Смещение исключения: 000000000009970a
Версия ОС: 6.1.7601.2.1.0.256.1
Код языка: 1049
Дополнительные сведения 1: 4c0d
Дополнительные сведения 2: 4c0d4d78887f76d971d5d00f1f20a433
Дополнительные сведения 3: 4c0d
Дополнительные сведения 4: 4c0d4d78887f76d971d5d00f1f20a433

schwa_quark_Неправильно процитировал.
пропущено...


Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
пропущено...

Нет. Это баг JVM. А то, что я написал это нарушение последовательного выполнения программы, которое не может возникнуть сейчас. И никакое final у переменной не влияет в примере ни на что абсолютно. К тому же в JMM всеми этими фичами наделены исключительно поля. См. 17.5. final Field Semantics Java Spec

Вы правы.