Произойдет ли непостоянное чтение перед изменяющейся записью?

Нет, энергозависимое чтение до (в порядке синхронизации) энергозависимой записи той же переменной не обязательно происходит до энергозависимой записи.

Это означает, что они могут участвовать в «гонке за данные», потому что это «конфликтующие обращения, не упорядоченные отношениями« происходит раньше »». Если это правда, то почти все программы содержат гонки данных :) Но, вероятно, это ошибка спецификации. Неустойчивые операции чтения и записи никогда не следует рассматривать как гонку за данными. Если все переменные в программе изменчивы, все выполнения тривиально последовательно согласованы. см. http://cs.oswego.edu/pipermail/concurrency-interest/2012-January/008927.html

1 происходит раньше 2, почему?

Я не на 100% уверен, что понимаю ваш вопрос.

Если у вас есть изменчивая переменная a и один поток читает из нее, а другой записывает в нее, порядок этих обращений может быть в любом порядке. Это состояние гонки. Что гарантируется JVM и моделью памяти Java (JMM), зависит от того, какая операция выполняется первой.

Запись могла произойти только что, и при чтении будет обнаружено обновленное значение. Или запись могла произойти после чтения. Таким образом, x может быть либо 5, либо предыдущим значением a.

каждое последовательное выполнение согласованности должно происходить до связи между этими обращениями

Я не уверен, что это значит, поэтому постараюсь уточнить. Связь «происходит до» с volatile означает, что все предыдущие записи памяти в переменную volatile до чтения той же переменной гарантированно завершены. Но эта гарантия никоим образом не объясняет время между двумя volatile операциями, которые зависят от состояния гонки. Читатель гарантированно видел запись, но только, если запись произошла до чтения.

Вы можете подумать, что это довольно слабая гарантия, но в потоках, производительность которых значительно улучшена за счет использования локального кеша ЦП, чтение значения поля может происходить из сегмента кэшированной памяти, а не из центральной памяти. Гарантия имеет решающее значение для обеспечения того, чтобы локальная память потока была недействительной и обновлялась при чтении volatile, чтобы потоки могли надлежащим образом обмениваться данными.

Опять же, JVM и JMM гарантируют, что если вы читаете из поля volatile a, то любые записи в это же поле, которые произошли до чтения, будут видны им - записанное значение будут правильно опубликованы и видны читающей ветке. Однако эта гарантия никоим образом не определяет порядок заказа. Он не говорит, что запись должна произойти до чтения.

Извините, но вы не можете правильно сказать, как JVM оптимизирует код в зависимости от «модели памяти» JVM. Вы должны использовать высокоуровневые инструменты Java для определения того, что вы хотите.

Таким образом, изменчивость означает только то, что для переменных не будет использоваться «межпоточный кеш».

Если вы хотите более строгий порядок, вы должны использовать синхронизированные блоки.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

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

volatile int a;
int b =0;
Thread-1:
   b = 5;
   a = 10;
Thread-2
   c = b + a;

В этом случае «не произошло» раньше, a может быть либо 10, либо 0, а b может быть либо 5, либо 0, поэтому в результате c может быть либо 0, 5, 10 или 15. Если чтение a подразумевает какое-то другое условие, то устанавливается, что произошло раньше, например:

int b = 0;
volatile int a = 0;
Thread-1:
   b = 5
   a = 10;
Thread 2: 
   if(a == 10){
      c = b + a;
   }

В этом случае вы гарантируете c = 15, потому что чтение a==10 подразумевает, что запись b = 5 происходит до записи a = 10.

Изменить: обновление порядка добавления, как отметил Грей, несоответствие