Чому ця програма Java припиняється, незважаючи на те, що, мабуть, вона не повинна (і не стала)?

Чутлива операція в моїй лабораторії сьогодні пішла зовсім не так. Привід на електронному мікроскопі перейшов його межу, і після ланцюжка подій я втратив обладнання в $ 12 млн. Я звузив більше ніж 40 К рядків у несправному модулі до цього:

import java.util.*;

class A {
    static Point currentPos = new Point(1,2);
    static class Point {
        int x;
        int y;
        Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }
    public static void main(String[] args) {
        new Thread() {
            void f(Point p) {
                synchronized(this) {}
                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();
        while (true)
            currentPos = new Point(currentPos.x+1, currentPos.y+1);
    }
}

Деякі зразки результатів, які я отримую:

$ java A
145281 145282
$ java A
141373 141374
$ java A
49251 49252
$ java A
47007 47008
$ java A
47427 47428
$ java A
154800 154801
$ java A
34822 34823
$ java A
127271 127272
$ java A
63650 63651

Оскільки тут немає арифметики з плаваючою комою, і всі ми знаємо, що підписані цілі числа добре поводяться при переповненні Java, я думаю, що в цьому коді нічого поганого. Однак, незважаючи на вихід, який вказує на те, що програма не досягла умови виходу, вона досягла умови виходу (вона була досягнута і не досягнута?). Чому?

Я помітив, що цього не відбувається в деяких умовах. Я на OpenJDK 6 на 64-розрядному Linux.

Очевидно, що запис у 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) {}СВМ може сприйматись як неприйняття (я розумію, ви включили його для відтворення поведінки).

Оскільки currentPosвін змінюється поза потоком, його слід позначити як volatile:

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

Без мінливості нитка не гарантується читати в оновленнях до 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 та його поля за ним, спільне між двома потоками, без синхронізації. Таким чином, не існує визначеного впорядкування між записами, які трапляються з цією пам'яттю в основному потоці, і зчитуваннями в створеному потоці (називаємо це T).

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

• до px
• до пі
• до поточнихпостів

Оскільки у цих записах немає нічого особливого з точки зору синхронізації / бар'єрів, час виконання може вільно дозволити потоку Т побачити, що вони виникають у будь-якому порядку (головний потік, звичайно, завжди бачить, як записується і читається впорядковано відповідно до програмного замовлення), і відбуваються у будь-яку точку між прочитаними в Т.

Так T робить:

1. читає currentpos на с
2. читати px та py (у будь-якому порядку)
3. порівняйте і візьміть гілку
4. читати px та py (будь-який порядок) та викликати System.out.println

Зважаючи на відсутність впорядкованих зв’язків між записом в основному і прочитаними в T, очевидно, є кілька способів, як це може призвести до вашого результату, оскільки T може побачити запис основного в currentpos перед записом в currentpos.y або currentpos.x:

1. Спочатку він читає currentpos.x, перш ніж сталося записування x - отримує 0, потім читає currentpos.y до того, як y запис відбулося - отримує 0. Порівняйте овалі з істинними. Записи стають видимими для T. System.out.println.
2. Спочатку він читає currentpos.x, після того, як відбулося записування x, а потім читає currentpos.y до того, як y запис відбулося - отримує 0. Порівняйте овалі з істинними. Записи стають видимими для T ... і т.д.
3. Спочатку він читає currentpos.y, перш ніж відбудеться запис y (0), потім читає currentpos.x після запису x, дорівнює справжньому. тощо.

і так далі ... Тут є ряд перегонів даних.

Я підозрюю, що тут недосконалим припущенням є думка про те, що записи, отримані з цього рядка, стають видимими для всіх потоків у програмному порядку потоку, що виконує його:

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

Java не дає такої гарантії (це буде жахливо для продуктивності). Щось більше потрібно додати, якщо вашій програмі потрібне гарантоване впорядкування записів відносно читання в інших потоках. Інші пропонують зробити поля x, y остаточними або, як альтернативу, зробити струми непостійними.

• Якщо ви зробите поля x, y остаточними, тоді Java гарантує, що записування їх значень буде видно, перш ніж конструктор повернеться, у всіх потоках. Таким чином, оскільки призначення конструктору topospos після конструктора, T-потік гарантовано бачить записи в правильному порядку.
• Якщо ви робите currentpos мінливими, Java гарантує, що це точка синхронізації, яка буде повністю упорядкована wrt іншими точками синхронізації. Як і в основному, запис в x і y повинен відбуватися перед записом в currentpos, тоді будь-яке зчитування currentpos в іншому потоці повинно бачити також записи x, y, що відбувалися раніше.

Використання final має ту перевагу, що це робить поля непорушними, і, таким чином, дозволяє кешувати значення. Використання непостійних призводить до синхронізації кожного запису та читання поточних записів, що може зашкодити продуктивності.

Докладні відомості див. У главі 17 Спеціалізації мови Java: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

(Первісна відповідь передбачала слабку модель пам'яті, тому що я не був впевнений, що гарантована мінливість JLS є достатньою. Відповідь відредаговано, щоб відобразити коментар Assylias, вказуючи на те, що модель Java сильніша - буває раніше, ніж є перехідною - і тому мінливою для поточнихпозицій також достатньо ).

Ви можете використовувати об'єкт для синхронізації записів і читання. В іншому випадку, як говорили інші раніше, запис у currentPos відбудеться в середині двох зчитувань p.x + 1 і py

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. х = 10, у = 11
2. робоча нитка оцінює px як 10
3. головний потік виконує оновлення, тепер x = 11 і y = 12
4. робоча нитка оцінює py як 12
5. робоча нитка помічає, що 10 + 1! = 12, тому друкує та виходить.

Ви по суті порівнюєте дві різні точки.

Зауважте, що навіть зробити currentPos змінним не захистить вас від цього, оскільки це два окремих читання робочої нитки.

Додайте

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

метод до вашого класу балів. Це забезпечить використання лише одного значення currentPos під час перевірки х + 1 == у.