Dlaczego ten program Java kończy działanie, mimo że najwyraźniej nie powinien (i nie zrobił)?

Czuła operacja w moim laboratorium dzisiaj poszła całkowicie nie tak. Siłownik mikroskopu elektronowego przekroczył granicę, a po łańcuchu wydarzeń straciłem sprzęt o wartości 12 milionów dolarów. Zawęziłem ponad 40 000 linii w wadliwym module do tego:

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);
    }
}

Niektóre próbki danych wyjściowych, które otrzymuję:

$ 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

Ponieważ nie ma tutaj żadnej arytmetyki zmiennoprzecinkowej i wszyscy wiemy, że liczby całkowite ze znakiem zachowują się dobrze w przypadku przepełnienia w Javie, sądzę, że nie ma nic złego w tym kodzie. Jednak pomimo danych wyjściowych wskazujących, że program nie osiągnął warunku wyjścia, osiągnął warunek wyjścia (został osiągnięty i nie został osiągnięty?). Czemu?

Zauważyłem, że tak się nie dzieje w niektórych środowiskach. Korzystam z OpenJDK 6 na 64-bitowym systemie Linux.

Oczywiście zapis do currentPos nie ma miejsca - przed jego przeczytaniem, ale nie rozumiem, jak to może być problem.

currentPos = new Point(currentPos.x+1, currentPos.y+1);robi kilka rzeczy, w tym zapisuje wartości domyślne do xi y(0), a następnie zapisuje swoje wartości początkowe w konstruktorze. Ponieważ obiekt nie został bezpiecznie opublikowany, te 4 operacje zapisu mogą być dowolnie zmieniane przez kompilator / JVM.

Tak więc z punktu widzenia wątku czytającego jest legalnym wykonaniem, aby czytać xz nową wartością, ale yna przykład z domyślną wartością 0. Zanim dotrzesz do printlninstrukcji (która, nawiasem mówiąc, jest zsynchronizowana i dlatego wpływa na operacje odczytu), zmienne mają swoje wartości początkowe, a program wypisuje wartości oczekiwane.

Oznaczenie currentPosjako volatilezapewni bezpieczną publikację, ponieważ Twój obiekt jest faktycznie niezmienny - jeśli w twoim rzeczywistym przypadku obiekt zostanie zmutowany po budowie, volatilegwarancje nie będą wystarczające i ponownie zobaczysz niespójny obiekt.

Alternatywnie możesz zrobić Pointniezmienne, które zapewni również bezpieczną publikację, nawet bez użycia volatile. Aby osiągnąć niezmienność, wystarczy zaznaczyć xi yzakończyć.

Jako dodatkowa uwaga i jak już wspomniano, synchronized(this) {}JVM może potraktować ją jako zakaz operacji (rozumiem, że uwzględniłeś ją w celu odtworzenia zachowania).

Ponieważ currentPosjest zmieniany poza wątkiem, należy go oznaczyć jako volatile:

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

Bez niestabilności nie ma gwarancji, że wątek będzie czytał aktualizacje programu currentPos, które są tworzone w głównym wątku. Tak więc nowe wartości są nadal zapisywane dla currentPos, ale wątek nadal używa poprzednich wersji buforowanych ze względu na wydajność. Ponieważ tylko jeden wątek modyfikuje currentPos, możesz uciec bez blokad, co poprawi wydajność.

Wyniki wyglądają znacznie inaczej, jeśli odczytasz wartości tylko raz w wątku, aby użyć ich w porównaniu i późniejszym ich wyświetleniu. Kiedy to robię, poniższe xzawsze są wyświetlane jako 1i yróżnią się między 0pewną dużą liczbą całkowitą. Myślę, że jego zachowanie w tym momencie jest nieco niezdefiniowane bezvolatile słowa kluczowego i możliwe jest, że kompilacja kodu JIT przyczynia się do tego, że działa on w ten sposób. Również jeśli skomentuję pusty synchronized(this) {}blok, kod również działa i podejrzewam, że dzieje się tak, ponieważ blokowanie powoduje wystarczające opóźnienie, currentPosa jego pola są ponownie odczytywane, a nie używane z pamięci podręcznej.

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

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

Masz zwykłą pamięć, odniesienie „currentpos” oraz obiekt Point i jego pola za nim, współdzielone między 2 wątkami, bez synchronizacji. Zatem nie ma zdefiniowanego porządku między zapisem, który ma miejsce w tej pamięci w głównym wątku, a odczytami w utworzonym wątku (nazwij go T).

Główny wątek wykonuje następujące zapisy (zignorowanie początkowej konfiguracji punktu, spowoduje, że px i py będą miały wartości domyślne):

• do px
• do py
• do currentpos

Ponieważ w tych zapisach nie ma nic specjalnego pod względem synchronizacji / barier, środowisko wykonawcze może dowolnie pozwolić, aby wątek T zobaczył, że występują one w dowolnej kolejności (główny wątek oczywiście zawsze widzi zapisy i odczyty uporządkowane zgodnie z kolejnością programów) i występują w dowolnym punkcie między odczytami w T.

Więc T robi:

1. czyta currentpos do p
2. odczytać px i py (w dowolnej kolejności)
3. porównaj i weź oddział
4. odczytać px i py (jedno zamówienie) i wywołać System.out.println

Biorąc pod uwagę, że nie ma powiązań porządkowych między zapisami w main, a odczytami w T, istnieje oczywiście kilka sposobów, dzięki którym można uzyskać wynik, ponieważ T może zobaczyć zapis main w currentpos przed zapisami w currentpos.y lub currentpos.x:

1. Najpierw odczytuje currentpos.x, przed wystąpieniem zapisu x - dostaje 0, a następnie odczytuje currentpos.y przed wystąpieniem zapisu y - dostaje 0. Porównaj evals z prawdą. Zapisy stają się widoczne dla T. System.out.println nazywa się.
2. Najpierw odczytuje currentpos.x, po wystąpieniu zapisu x, a następnie odczytuje currentpos.y przed wystąpieniem zapisu y - dostaje 0. Porównaj evals z prawdą. Zapisy stają się widoczne dla T ... itd.
3. Najpierw odczytuje currentpos.y, zanim nastąpi zapis y (0), a następnie odczytuje currentpos.x po zapisie x, zmienia się na true. itp.

i tak dalej ... Jest tu wiele wyścigów danych.

Podejrzewam, że błędne założenie polega na tym, że zapisy, które wynikają z tego wiersza, są widoczne we wszystkich wątkach w kolejności programowej wykonywanego wątku:

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

Java nie daje takiej gwarancji (byłoby to fatalne z punktu widzenia wydajności). Coś więcej trzeba dodać, jeśli twój program potrzebuje gwarantowanej kolejności zapisów w stosunku do odczytów w innych wątkach. Inni sugerowali, aby pola x, y były ostateczne, lub alternatywnie uczynić prądy prądu zmiennymi.

• Jeśli ustawisz pola x, y jako końcowe, wówczas Java gwarantuje, że zapis ich wartości będzie widoczny przed powrotem konstruktora we wszystkich wątkach. Tak więc, ponieważ przypisanie do currentpos następuje po konstruktorze, wątek T gwarantuje, że zapisy będą we właściwej kolejności.
• Jeśli sprawisz, że currentpos będzie niestabilny, wówczas Java gwarantuje, że jest to punkt synchronizacji, który zostanie w całości uporządkowany względem innych punktów synchronizacji. Jak w zasadzie zapisy do xiy muszą się zdarzyć przed zapisem do currentpos, to każdy odczyt currentpos w innym wątku musi także zobaczyć zapisy x, y, które miały miejsce wcześniej.

Korzystanie z parametru final ma tę zaletę, że sprawia, że ​​pola są niezmienne, a zatem umożliwia buforowanie wartości. Korzystanie z niestabilnych prowadzi do synchronizacji przy każdym zapisie i odczycie prądów prądowych, co może zaszkodzić wydajności.

Szczegółowe informacje na ten temat można znaleźć w rozdziale 17 specyfikacji języka Java: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

(Początkowa odpowiedź zakładała słabszy model pamięci, ponieważ nie byłem pewien, czy gwarantowana zmienność JLS jest wystarczająca. Odpowiedź edytowana w celu odzwierciedlenia komentarza od assylias, wskazując, że model Java jest silniejszy - zdarza się, zanim jest przechodni - i tak niestabilny na prądach również wystarcza ).

Możesz użyć obiektu do synchronizacji zapisów i odczytów. W przeciwnym razie, jak powiedziano wcześniej, zapis do currentPos nastąpi w środku dwóch odczytów p.x + 1 i 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);
    }
}

Uzyskujesz dostęp do currentPos dwa razy i nie dajesz żadnej gwarancji, że nie zostanie on zaktualizowany pomiędzy tymi dwoma dostępami.

Na przykład:

1. x = 10, y = 11
2. wątek roboczy ocenia px jako 10
3. główny wątek wykonuje aktualizację, teraz x = 11 i y = 12
4. wątek roboczy ocenia py jako 12
5. wątek roboczy zauważa, że ​​10 + 1! = 12, więc drukuje i wychodzi.

Zasadniczo porównujesz dwa różne punkty.

Zwróć uwagę, że nawet zmienność currentPos nie ochroni cię przed tym, ponieważ są to dwa osobne odczyty dla wątku roboczego.

Dodaj

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

metoda do twojej klasy punktów. Zapewni to, że podczas sprawdzania x + 1 == y zostanie użyta tylko jedna wartość currentPos.