Warum wird dieses Java-Programm trotzdem beendet, sollte es anscheinend nicht (und nicht)?

Eine sensible Operation in meinem Labor ist heute völlig schief gelaufen. Ein Aktuator auf einem Elektronenmikroskop überschritt seine Grenzen, und nach einer Kette von Ereignissen verlor ich 12 Millionen Dollar an Ausrüstung. Ich habe über 40K Zeilen im fehlerhaften Modul auf diese eingegrenzt:

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

Einige Beispiele der Ausgabe, die ich bekomme:

$ 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

Da es hier keine Gleitkomma-Arithmetik gibt und wir alle wissen, dass sich vorzeichenbehaftete Ganzzahlen beim Überlauf in Java gut verhalten, würde ich denken, dass an diesem Code nichts falsch ist. Obwohl die Ausgabe anzeigt, dass das Programm die Beendigungsbedingung nicht erreicht hat, hat es die Beendigungsbedingung erreicht (es wurde sowohl erreicht als auch nicht erreicht?). Warum?

Ich habe festgestellt, dass dies in einigen Umgebungen nicht der Fall ist. Ich bin auf OpenJDK 6 unter 64-Bit-Linux.

Offensichtlich findet das Schreiben in currentPos nicht statt - vor dem Lesen, aber ich sehe nicht, wie das das Problem sein kann.

currentPos = new Point(currentPos.x+1, currentPos.y+1);führt einige Dinge aus, einschließlich des Schreibens von Standardwerten in xund y(0) und des anschließenden Schreibens ihrer Anfangswerte in den Konstruktor. Da Ihr Objekt nicht sicher veröffentlicht wird, können diese 4 Schreibvorgänge vom Compiler / JVM frei neu angeordnet werden.

Aus der Sicht des Lesethreads ist es also eine legale Ausführung, xmit seinem neuen Wert zu lesen , aber beispielsweise ymit seinem Standardwert 0. Wenn Sie die printlnAnweisung erreichen (die übrigens synchronisiert ist und daher die Leseoperationen beeinflusst), haben die Variablen ihre Anfangswerte und das Programm druckt die erwarteten Werte.

Das Markieren currentPosals volatilegewährleistet eine sichere Veröffentlichung, da Ihr Objekt effektiv unveränderlich ist. Wenn das Objekt in Ihrem tatsächlichen Anwendungsfall nach der Erstellung mutiert volatilewird, reichen Garantien nicht aus und Sie können ein inkonsistentes Objekt erneut sehen.

Alternativ können Sie das PointUnveränderliche herstellen, wodurch auch ohne Verwendung eine sichere Veröffentlichung gewährleistet wird volatile. Um Unveränderlichkeit zu erreichen, müssen Sie nur markieren xund yabschließen.

Als Randnotiz und wie bereits erwähnt, synchronized(this) {}kann von der JVM als No-Op behandelt werden (ich verstehe, dass Sie es aufgenommen haben, um das Verhalten zu reproduzieren).

Da currentPosaußerhalb des Threads geändert wird, sollte es markiert werden als volatile:

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

Ohne flüchtig kann der Thread nicht garantiert Aktualisierungen von currentPos einlesen, die im Hauptthread vorgenommen werden. Daher werden weiterhin neue Werte für currentPos geschrieben, aber der Thread verwendet aus Leistungsgründen weiterhin die vorherigen zwischengespeicherten Versionen. Da nur ein Thread currentPos ändert, können Sie ohne Sperren davonkommen, was die Leistung verbessert.

Die Ergebnisse sehen sehr unterschiedlich aus, wenn Sie die Werte nur ein einziges Mal innerhalb des Threads lesen, um sie zu vergleichen und anschließend anzuzeigen. Wenn ich dies tue, wird Folgendes ximmer als 1und yzwischen 0einer großen Ganzzahl angezeigt . Ich denke, das Verhalten an dieser Stelle ist ohne das volatileSchlüsselwort etwas undefiniert und es ist möglich, dass die JIT-Kompilierung des Codes dazu beiträgt, dass es sich so verhält. Auch wenn ich den leeren synchronized(this) {}Block auskommentiere, funktioniert der Code ebenfalls und ich vermute, dass das Sperren eine ausreichende Verzögerung verursacht currentPosund die Felder erneut gelesen und nicht aus dem Cache verwendet werden.

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

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

Sie haben normalen Speicher, die 'currentpos'-Referenz und das Point-Objekt und seine Felder dahinter, die von zwei Threads ohne Synchronisation gemeinsam genutzt werden. Daher gibt es keine definierte Reihenfolge zwischen den Schreibvorgängen, die in diesem Speicher im Hauptthread ausgeführt werden, und den Lesevorgängen im erstellten Thread (nennen Sie es T).

Der Hauptthread führt die folgenden Schreibvorgänge aus (das Ignorieren der anfänglichen Einrichtung von point führt dazu, dass px und py Standardwerte haben):

• zu px
• zu py
• zu currentpos

Da diese Schreibvorgänge in Bezug auf Synchronisation / Barrieren nichts Besonderes sind, ist die Laufzeit frei, damit der T-Thread sie in beliebiger Reihenfolge sehen kann (der Haupt-Thread sieht natürlich immer Schreib- und Lesevorgänge, die gemäß der Programmreihenfolge sortiert sind) und auftreten zu jedem Zeitpunkt zwischen den Lesevorgängen in T.

Also macht T:

1. liest currentpos auf p
2. Lesen Sie px und py (in beliebiger Reihenfolge)
3. Vergleiche und nimm den Zweig
4. Lesen Sie px und py (in beliebiger Reihenfolge) und rufen Sie System.out.println auf

Da es keine Ordnungsbeziehungen zwischen den Schreibvorgängen in main und den Lesevorgängen in T gibt, gibt es eindeutig mehrere Möglichkeiten, wie Sie Ihr Ergebnis erzielen können, da T möglicherweise das Schreiben von main in currentpos vor den Schreibvorgängen in currentpos.y oder currentpos.x sieht:

1. Es liest zuerst currentpos.x, bevor der x-Schreibvorgang stattgefunden hat - erhält 0, dann liest currentpos.y, bevor der y-Schreibvorgang stattgefunden hat - erhält 0. Vergleiche evals mit true. Die Schreibvorgänge werden für T. sichtbar. System.out.println wird aufgerufen.
2. Es liest zuerst currentpos.x, nachdem das x-Schreiben stattgefunden hat, und liest dann currentpos.y, bevor das y-Schreiben stattgefunden hat - erhält 0. Vergleiche evals mit true. Schriften werden für T ... usw. sichtbar.
3. Es liest zuerst currentpos.y, bevor der y-Schreibvorgang stattgefunden hat (0), und liest dann currentpos.x, nachdem der x-Schreibvorgang auf true ausgewertet wurde. etc.

und so weiter ... Hier gibt es eine Reihe von Datenrennen.

Ich vermute, dass die fehlerhafte Annahme hier darin besteht, dass die aus dieser Zeile resultierenden Schreibvorgänge über alle Threads in der Programmreihenfolge des Threads sichtbar gemacht werden, der sie ausführt:

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

Java gibt keine solche Garantie (es wäre schrecklich für die Leistung). Es muss noch etwas hinzugefügt werden, wenn Ihr Programm eine garantierte Reihenfolge der Schreibvorgänge in Bezug auf Lesevorgänge in anderen Threads benötigt. Andere haben vorgeschlagen, die x-, y-Felder endgültig zu machen oder alternativ currentpos flüchtig zu machen.

• Wenn Sie die Felder x, y endgültig machen, garantiert Java, dass die Schreibvorgänge ihrer Werte in allen Threads ausgeführt werden, bevor der Konstruktor zurückkehrt. Da die Zuweisung zu currentpos nach dem Konstruktor erfolgt, wird dem T-Thread garantiert, dass die Schreibvorgänge in der richtigen Reihenfolge angezeigt werden.
• Wenn Sie currentpos flüchtig machen, garantiert Java, dass dies ein Synchronisationspunkt ist, der für andere Synchronisationspunkte insgesamt geordnet ist. Wie in der Regel müssen die Schreibvorgänge in x und y vor dem Schreiben in currentpos erfolgen. Bei jedem Lesen von currentpos in einem anderen Thread müssen auch die zuvor beschriebenen Schreibvorgänge von x, y angezeigt werden.

Die Verwendung von final hat den Vorteil, dass die Felder unveränderlich werden und die Werte zwischengespeichert werden können. Die Verwendung von flüchtigen Daten führt zu einer Synchronisierung bei jedem Schreiben und Lesen von aktuellen Poss, was die Leistung beeinträchtigen kann.

Weitere Informationen finden Sie in Kapitel 17 der Java-Sprachspezifikation: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

(Bei der ersten Antwort wurde von einem schwächeren Speichermodell ausgegangen, da ich nicht sicher war, ob die von JLS garantierte Volatilität ausreicht. Die Antwort wurde bearbeitet, um den Kommentar von Assylias widerzuspiegeln ).

Sie können ein Objekt verwenden, um die Schreib- und Lesevorgänge zu synchronisieren. Andernfalls erfolgt, wie bereits erwähnt, ein Schreiben in currentPos in der Mitte der beiden Lesevorgänge p.x + 1 und 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);
    }
}

Sie greifen zweimal auf currentPos zu und geben keine Garantie dafür, dass es zwischen diesen beiden Zugriffen nicht aktualisiert wird.

Beispielsweise:

1. x = 10, y = 11
2. Worker-Thread wertet px als 10 aus
3. Der Hauptthread führt das Update aus, jetzt x = 11 und y = 12
4. Worker-Thread bewertet py als 12
5. Der Arbeitsthread bemerkt, dass 10 + 1! = 12 ist, druckt und beendet sich.

Sie vergleichen im Wesentlichen zwei verschiedene Punkte.

Beachten Sie, dass selbst wenn Sie currentPos flüchtig machen, Sie nicht davor geschützt sind, da es zwei separate Lesevorgänge durch den Worker-Thread sind.

Fügen Sie eine hinzu

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

Methode zu Ihrer Punkteklasse. Dadurch wird sichergestellt, dass bei der Überprüfung von x + 1 == y nur ein Wert von currentPos verwendet wird.