Как JVM внутренне управляет условиями гонки?

Question

Если несколько потоков пытаются обновить одну и ту же переменную-член, это называется условием гонки. Но меня больше интересовало, как JVM обрабатывает его внутренне, если мы не будем обрабатывать его в нашем коде, сделав его синхронизированным или что-то еще? Будет ли это зависать моя программа? Как будет реагировать JVM на это? Я думал, что JVM временно создаст блок синхронизации для этой ситуации, но я не уверен, что именно произойдет.

Если у вас есть какое-то понимание, было бы хорошо знать.

Answer 1

Точный термин раса данные, которая является конкретизацией общей концепции состояния гонки. Термин гонка данных является официальной четко определенной концепцией, что означает, что она возникает из формального анализа кода.

Единственный способ получить реальное изображение - перейти к изучению главы модели памяти в Спецификации языка Java, но это упрощенное представление: всякий раз, когда у вас есть гонка данных, почти нет гарантии относительно результата и поток чтения может видеть любое значение, которое когда-либо было записано в переменную. В этом и заключается единственная гарантия: нить будет не наблюдать за значением «вне тонкого воздуха», которое никогда не было написано. Хорошо, если вы не имеете дело с long s или double s, тогда вы можете увидеть порванные записи.

Answer 2

Возможно, мне что-то не хватает, но что с этим нужно обращаться? По-прежнему есть поток, который попадет туда первым. В зависимости от того, какой поток есть, этот поток будет просто обновлять/читать некоторую переменную и перейти к следующей инструкции. Он не может магически построить блок синхронизации, он действительно не знает, что вы хотите сделать. То есть, другими словами, то, что произойдет, будет зависеть от результата «расы».

Примечание. Я не сильно разбираюсь в материалах нижнего уровня, поэтому, возможно, я не полностью понимаю глубину вашего вопроса.

Answer 3

Java предоставляет synchronized и volatile для решения этих ситуаций. Использование их должным образом может быть довольно сложно, но имейте в виду, что Java только раскрывает сложность современных архитектур процессора и памяти. Альтернативами было бы всегда ошибаться на стороне осторожности, эффективно синхронизировать все, что могло бы убить производительность; или игнорировать проблему и не предлагать никакой безопасности потока. И, к счастью, Java обеспечивает отличные конструкторы высокого уровня в пакете java.util.concurrent, поэтому вы часто можете избегать работы с низкоуровневыми материалами.

Answer 4

JVM прекрасно справится с ситуацией (то есть не будет висеть или жаловаться), но вы не можете получить результат, который вам нравится!

Когда задействовано несколько потоков, java становится ужасно сложным, и даже код, который выглядит явно правильным, может оказаться ужасно сломанным. В качестве примера:

public class IntCounter { 
    private int i; 

    public IntCounter(int i){ 
     this.i = i; 
    } 

    public void incrementInt(){ 
     i++; 
    } 

    public int getInt(){ 
     return i; 
    } 
} 

имеет недостатки во многих отношениях.

Во-первых, предположим, что i в настоящее время 0 и нить A и нить B оба вызова incrementInt() примерно в то же время. Существует опасность того, что они оба увидят, что i равно 0, затем оба увеличивают его 1, а затем сохраняют результат. Поэтому в конце двух вызовов я только 1, а не 2!

Это проблема состояния гонки с кодом, но есть и другие проблемы, касающиеся видимости памяти.Когда поток A изменяет общую переменную, нет гарантии (без синхронизации), что нить B когда-либо увидит изменения!

Таким образом, поток A может увеличивать i 100 раз, а через час поток B, вызывая getInt(), может видеть i как 0 или 100 или где-нибудь посередине!

Единственная нормальная вещь, которую нужно сделать, если вы вникаете в java-параллелизм, - это прочитать параллельность Java на практике Брайана Гетца и др. (OK есть, вероятно, другие хорошие способы, чтобы узнать об этом, но это большая книге со написано Джошуа Блох, Дуг Леа и другие)

Answer 5

Короче, виртуальная машина предполагает что код свободен от гонок данных при переводе это в машинный код. То есть, если код не был правильно синхронизирован, спецификация языка Java предоставляет только ограниченные гарантии о поведении этого кода.

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

В частности, спецификации языка Java guarantees следующее только в отсутствии каких-либо расы данных:

• видимости: чтение поля дает значение последнем возложенное на него (не ясно, какую запись была последнего и пишет длинный или двойные переменные need not be atomic)

• заказывающих: если запись видна, поэтому какая-либо запись, предшествующая его. Например, если один поток выполняет:

  x = new FancyObject(); 
  

  другой поток может читать x только после того, как конструктор FancyObject выполнил полностью.

При наличии гонки данных эти гарантии являются недействительными. Возможно, что нить чтения никогда не увидит запись. Также можно увидеть запись x, не видя эффекта конструктора, который логически предшествовал записи x. Очень маловероятно, что программа верна, если такие базовые предположения не могут быть сделаны.

Гонка данных, однако, не поставит под угрозу целостность виртуальной машины Java. В частности, JVM не будет выходить из строя или останавливаться, а также гарантировать безопасность памяти (т. Е. Предотвратить повреждение памяти) и certain semantics of final fields.