Почему эта Java-программа завершается, несмотря на то, что, по-видимому, она не должна (и не должна)?

Очевидно, что запись в currentPos не происходит до чтения, но я не понимаю, как это может быть проблемой.

currentPos = new Point(currentPos.x+1, currentPos.y+1); делает несколько вещей, в том числе записывает значения по умолчанию в x и y (0), а затем записывает их начальные значения в конструкторе. Поскольку ваш объект не опубликован безопасно, эти 4 операции записи могут быть свободно переупорядочены компилятором/JVM.

Таким образом, с точки зрения потока чтения допустимо чтение x с его новым значением, но y со значением по умолчанию, например, 0. К тому времени, когда вы достигаете оператора println (который, кстати, синхронизирован и, следовательно, влияет на операции чтения), переменные имеют свои начальные значения, и программа выводит ожидаемые значения.

Пометка currentPos как volatile обеспечит безопасную публикацию, поскольку ваш объект фактически неизменяем - если в вашем реальном случае использования объект мутирует после создания, гарантий volatile будет недостаточно, и вы снова можете увидеть несогласованный объект.

Кроме того, вы можете сделать Point неизменяемым, что также обеспечит безопасную публикацию, даже без использования volatile. Чтобы добиться неизменности, вам просто нужно отметить x и y окончательными.

В качестве примечания, как уже упоминалось, synchronized(this) {} может рассматриваться JVM как отсутствие операции (я понимаю, что вы включили его, чтобы воспроизвести поведение).

Поскольку currentPos изменяется вне потока, его следует пометить как volatile:

static volatile Point currentPos = new Point(1,2);

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

Результаты выглядят совсем по-другому, если вы читаете значения только один раз в потоке для использования при сравнении и последующем их отображении. Когда я делаю следующее, x всегда отображается как 1, а y варьируется от 0 до некоторого большого целого числа. Я думаю, что его поведение в этот момент несколько неопределенно без ключевого слова volatile, и возможно, JIT-компиляция кода способствует этому. Кроме того, если я закомментирую пустой блок synchronized(this) {}, тогда код тоже сработает, и я подозреваю, что это связано с тем, что блокировка вызывает достаточную задержку, чтобы currentPos и его поля перечитывались, а не использовались из кеша.

int x = p.x + 1;
int y = p.y;

if (x != y) {
    System.out.println(x+" "+y);
    System.exit(1);
}

У вас есть обычная память, ссылка «currentpos» и объект Point и его поля за ним, разделенные между двумя потоками без синхронизации. Таким образом, не существует определенного порядка между операциями записи, происходящими в этой памяти в основном потоке, и операциями чтения в созданном потоке (назовем его Т).

Основной поток выполняет следующие записи (игнорирование начальной настройки точки приведет к тому, что px и py будут иметь значения по умолчанию):

• to p.x
• to p.y
• to currentpos

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

Итак, Т делает:

1. читает currentpos в p
2. читать p.x и p.y (в любом порядке)
3. сравните и возьмите ветку
4. прочитать px и py (в любом порядке) и вызвать System.out.println

Учитывая, что между операциями записи в main и чтениями в T нет упорядоченных отношений, очевидно, что есть несколько способов, которыми это может привести к вашему результату, поскольку T может увидеть запись main в currentpos до записи в currentpos.y или currentpos.x:

1. Сначала он читает currentpos.x, до того, как произошла запись x — получает 0, затем читает currentpos.y до того, как произошла запись y — получает 0. Сравните evals с true. Записи становятся видимыми для T. Вызывается System.out.println.
2. Он сначала читает currentpos.x, после того как произошла запись x, затем читает currentpos.y до того, как произошла запись y, и получает 0. Сравните evals с истинным. Записи становятся видимыми для T... и т.д.
3. Сначала он считывает currentpos.y до того, как произойдет запись y (0), затем читает currentpos.x после записи x и возвращает значение true. и Т. Д.

и так далее... Здесь есть ряд гонок данных.

Я подозреваю, что ошибочное предположение здесь заключается в том, что записи, полученные в результате этой строки, становятся видимыми во всех потоках в порядке выполнения программы потока, выполняющего ее:

currentPos = new Point(currentPos.x+1, currentPos.y+1);

Java не дает такой гарантии (это было бы ужасно для производительности). Необходимо добавить что-то еще, если вашей программе требуется гарантированный порядок операций записи относительно операций чтения в других потоках. Другие предлагали сделать поля x,y окончательными или, в качестве альтернативы, сделать currentpos изменчивым.

• Если вы сделаете поля x,y окончательными, то Java гарантирует, что запись их значений будет замечена до возврата конструктора во всех потоках. Таким образом, поскольку присваивание currentpos выполняется после конструктора, поток T гарантированно увидит записи в правильном порядке.
• Если вы сделаете currentpos volatile, то Java гарантирует, что это точка синхронизации, которая будет полностью упорядочена по отношению к другим точкам синхронизации. Так как в main записи в x и y должны происходить до записи в currentpos, то любое чтение currentpos в другом потоке должно также видеть записи x, y, которые произошли раньше.

Использование final имеет то преимущество, что оно делает поля неизменяемыми и, таким образом, позволяет кэшировать значения. Использование volatile приводит к синхронизации при каждой записи и чтении currentpos, что может снизить производительность.

Подробности см. в главе 17 спецификации языка Java:http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

(Первоначальный ответ предполагал более слабую модель памяти, так как я не был уверен, что гарантированной изменчивости JLS было достаточно. Ответ отредактирован, чтобы отразить комментарий от assylias, указывая на то, что модель Java сильнее - происходит - до транзитивности - и поэтому изменчивости на currentpos также достаточно. ).

Вы можете использовать объект для синхронизации операций записи и чтения. В противном случае, как уже говорили другие, запись в currentPos произойдет в середине двух операций чтения p.x+1 и p.y.

new Thread() {
    void f(Point p) {
        if (p.x+1 != p.y) {
            System.out.println(p.x+" "+p.y);
            System.exit(1);
        }
    }
    @Override
    public void run() {
        while (currentPos == null);
        while (true)
            f(currentPos);
    }
}.start();
Object sem = new Object();
while (true) {
    synchronized(sem) {
        currentPos = new Point(currentPos.x+1, currentPos.y+1);
    }
}

Вы обращаетесь к currentPos дважды и не даете никаких гарантий, что он не обновится между этими двумя доступами.

Например:

1. x = 10, y = 11
2. рабочий поток оценивает p.x как 10
3. основной поток выполняет обновление, теперь x = 11 и y = 12
4. рабочий поток оценивает p.y как 12
5. рабочий поток замечает, что 10+1 != 12, поэтому печатает и завершает работу.

По сути, вы сравниваете две разные точки.

Обратите внимание, что даже создание currentPos volatile не защитит вас от этого, так как это два отдельных чтения рабочим потоком.

Добавить

boolean IsValid() { return x+1 == y; }

метод к вашему классу очков. Это гарантирует, что при проверке x+1 == y используется только одно значение currentPos.