Прочитать устаревшее значение поля после построения объекта

Я попытался проверить проблему с помощью следующего кода.

Тестовое задание:

public class Test {
    public static boolean flag =true;
    public static HolderContainer hc=new HolderContainer();

    public static void main (String args[]){    
        new Thread(new Initialization()).start();
        new Thread(new Checking()).start();
    }
}

class Initialization implements Runnable {
    public void run() {
        while (Test.flag){
            Test.hc=new HolderContainer();
            Test.hc.init();
            }
    }
}

class Checking implements Runnable {
    public void run() {
        try{
            Test.hc.holder.assertValue();
        }
        catch (NullPointerException e) {
        }    
    }
}

Держатель:

public class Holder {
    private int value;
        public Holder(int value) { 
        this.value = value;
    }

    public void assertValue() {
        if (value != value) {
            System.out.println("Magic");
            Test.flag=false;
        }
    }
}

class HolderContainer {
    public Holder holder;
    public void init() {
        holder = new Holder(42);  
    }
}

У меня никогда не было программы для оценки value!=value до true. Я не думаю, что это что-то доказывает, и не запускал его более пары минут, но я надеюсь, что это будет лучшей отправной точкой для хорошо разработанного теста или, по крайней мере, поможет выяснить некоторые возможные недостатки в тестах.

Я пытался вставить засыпание между Test.hc=new HolderContainer(); и Test.hc.init();, между public Holder holder; и public void init() { и после public void init() {.

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

Обратите внимание, что в принятом в настоящее время ответе на Неправильная публикация Справочника по объектам Java говорится, что эта проблема, вероятно, невозможна в архитектуре x86. Он также может зависеть от JVM.

Вероятно, вы пытаетесь смоделировать сценарий параллелизма, который, как мне кажется, очень сложно смоделировать с помощью пары потоков.

Следующий тестовый пример, который вы написали, совершенно неверен, с большей вероятностью выдаст NullPointerException.

public class Tests {

  private HolderContainer hc = new HolderContainer();

  class Initialization implements Runnable {
    public void run() {
      hc.init();
    }
  }

  class Checking implements Runnable {
    public void run() {
      hc.holder.assertValue();
    }
  }

  public void run() {
    new Thread(new Initialization()).start();  
    new Thread(new Checking()).start(); 
  }
}

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

Не воспроизводил это с вашим кодом. Вот пример имитации небезопасной публикации. Стратегия заключается в том, чтобы позволить одному потоку опубликовать Holder и позволить другому проверить его значение.

class Holder {
    private volatile int value;

    public Holder(int value, HolderContainer container) {
        container.holder = this;  // publication this object when it is not initilized properly
        try {
            Thread.sleep(10);  
        } catch (Exception e) {

        }
        this.value = value; // set value
    }

    public int getValue() {
        return value;
    }
}

class HolderContainer {

    public Holder holder;

    public Holder getHolder() { 
        if (holder == null) { 
            holder = new Holder(42, this);
        }
        return holder;
    }
}


public class Tests {

    public static void main(String[] args) {
        for (int loop = 0; loop < 1000; loop++) {
            HolderContainer holderContainer = new HolderContainer();
            new Thread(() -> holderContainer.getHolder()).start();
            new Thread(() -> {
                Holder holder = holderContainer.getHolder();
                int value1 = holder.getValue();  // might get default value
                try {
                    Thread.sleep(10);
                } catch (Exception e) {

                }
                int value2 = holder.getValue(); // might get custom value
                if (value1 != value2) {
                    System.out.println(value1 + "--->" + value2);
                }
            }).start();
        }
    }

}

Сон за 3 секунды перед назначением поля в конструкторе не имеет значения, потому что для того, чтобы value != value было true, первое чтение value должно привести к другому результату, чем второе, которое происходит сразу после.

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

Вот программа, которая выдает ошибку на x86. Он должен запускаться с параметром виртуальной машины: -XX:CompileCommand=dontinline,com/mypackage/Holder.getValue

package com.mypackage;

public class Test {
    public static void main(String[] args) {
        new Worker().start();
        int i = 1;
        while (true) {
            new Holder(i++);
        }
    }
}

class Holder {
    private int value;

    Holder(int value) {
        Worker.holder = this;
        this.value = value;
    }

    void assertSanity() {
        if (getValue() != getValue()) throw new AssertionError();
    }

    private int getValue() { return value; }
}

class Worker extends Thread {
    static Holder holder = new Holder(0);

    @Override
    public void run() {
        while (true) {
            holder.assertSanity();
        }
    }
}

Запрещая встраивание Holder#getValue(), мы предотвращаем сворачивание двух последующих чтений value в одно.

Эта оптимизация предотвращает появление ошибки в коде книги. Однако автор книги по-прежнему прав, поскольку эта оптимизация не является обязательной, поэтому с точки зрения модели памяти Java код неверен.

Метод assertSanity() равен:

int snapshot1 = getValue();
                            // <--- window of vulnerability, where the observed value can change
                            //      if you chose to sleep 3 seconds, you would want to do it here
                            //      takes very little time, less than 1 nanosecond
int snapshot2 = getValue();
if (snapshot1 != snapshot2) throw new AssertionError();

Таким образом, первое чтение value может дать значение по умолчанию int, равное 0 (называемое устаревшим значением и присвоенное в конструкторе Object()), а второе чтение может дать значение, назначенное в конструкторе Holder(int). Это могло бы произойти, если бы, например, значение, присвоенное в конструкторе, было передано потоку, вызывающему assertSanity(), в точный момент между двумя загрузками value (окно уязвимости).

То же самое произойдет, если мы отложим второе чтение другим способом, например:

int snapshot1 = this.value;
Thread.interrupted();
int snapshot2 = this.value;
if (snapshot1 != snapshot2) throw new AssertionError();