Использование ключевого слова volatile с изменяемым объектом

Это своего рода объяснение некоторых деталей volatile. Пишу это здесь, потому что это слишком много для комментария. Я хочу привести несколько примеров, которые показывают, как volatile влияет на видимость и как это изменилось в jdk 1.5.

Учитывая следующий пример кода:

public class MyClass
{
  private int _n;
  private volatile int _volN;

  public void setN(int i) {
    _n = i;
  }
  public void setVolN(int i) {
    _volN = i;
  }
  public int getN() { 
    return _n; 
  }
  public int getVolN() { 
    return _volN; 
  }

  public static void main() {
    final MyClass mc = new MyClass();

    Thread t1 = new Thread() {
      public void run() {
        mc.setN(5);
        mc.setVolN(5);
      }
    };

    Thread t2 = new Thread() {
      public void run() {
        int volN = mc.getVolN();
        int n = mc.getN();
        System.out.println("Read: " + volN + ", " + n);
      }
    };

    t1.start();
    t2.start();
  }
}

Поведение этого тестового кода четко определено в jdk1.5+, но не четко определено до jdk1.5.

В мире до jdk1.5 не было определенной связи между доступом к энергозависимым и энергонезависимым доступам. поэтому вывод этой программы может быть:

1. Чтение: 0, 0
2. Чтение: 0, 5
3. Читать: 5, 0
4. Читать: 5, 5

В мире jdk1.5+ семантика volatile была изменена, так что доступ к volatile влияет на доступ к энергонезависимому точно так же, как синхронизация. поэтому в мире jdk1.5+ возможны только определенные выходные данные:

1. Чтение: 0, 0
2. Чтение: 0, 5
3. Чтение: 5, 0 ‹- невозможно
4. Читать: 5, 5

Выход 3. невозможен, поскольку чтение «5» из volatile _volN устанавливает точку синхронизации между двумя потоками, что означает, что все действия из t1, предпринятые до назначения _volN, должны быть видимыми для t2 .

Дальнейшее чтение:

• Исправление модели памяти Java, часть 1
• Исправление модели памяти Java, часть 2

В вашем примере ключевое слово volatile гарантирует только то, что последняя ссылка, написанная любым потоком на «m», будет видна любому потоку, читающему «m» впоследствии.

Это ничего не гарантирует в отношении вашего get().

Итак, используя следующую последовательность:

Thread-1: get()     returns 2
Thread-2: set(3)
Thread-1: get()    

для вас совершенно законно вернуть 2, а не 3. volatile ничего в этом не меняет.

Но если вы измените свой класс Mutable на это:

class Mutable {
    private volatile int value;
    public int get()
    {
        return a;
    }
    public int set(int value)
    {
        this.value = value;
    }
}

Тогда гарантируется, что второй get() из Thread-1 вернет 3.

Однако обратите внимание, что volatile обычно не лучший метод синхронизации.

В вашем простом примере получения/установки (я знаю, что это всего лишь пример) класс, подобный AtomicInteger, использующий правильную синхронизацию и фактически предоставляющий полезные методы, был бы лучше.

volatile предоставляет только гарантии относительно ссылки на объект, объявленный таким образом. Члены этого экземпляра не синхронизируются.

Согласно Википедии, у вас есть:

• (Во всех версиях Java) Существует глобальный порядок чтения и записи в volatile переменную. Это означает, что каждый поток, обращающийся к изменчивому полю, будет считывать его текущее значение перед продолжением вместо того, чтобы (потенциально) использовать кешированное значение. (Однако нет никакой гарантии относительного порядка чтения и записи volatile с обычными операциями чтения и записи, а это означает, что это, как правило, бесполезная конструкция многопоточности.)
• (В Java 5 или более поздних версиях) Чтение и запись Volatile устанавливают отношения «происходит до», очень похоже на получение и освобождение мьютекса.

Итак, в основном у вас есть то, что, объявляя поле volatile, взаимодействуя с ним, создается «точка синхронизации», после которой любое изменение будет видно в других потоках. Но после этого использование get() или set() не синхронизируется. Спецификация Java объяснение.

Использование volatile вместо полного значения synchronized по существу является оптимизацией. Оптимизация исходит из более слабых гарантий, предоставляемых для значения volatile по сравнению с доступом synchronized. Преждевременная оптимизация — корень всех зол; в этом случае зло может быть трудно отследить, потому что оно будет в форме условий гонки и тому подобного. Поэтому, если вам нужно спросить, вы, вероятно, не должны использовать его.

volatile не "обеспечивает видимость". Его единственным эффектом является предотвращение кэширования переменной процессором, что обеспечивает отношение «происходит до» при одновременном чтении и записи. Он не влияет на члены объекта и не обеспечивает никакой синхронизации synchronized блокировки.

Поскольку вы не сказали нам, каково «правильное» поведение вашего кода, на вопрос нельзя ответить.