[Bekämpfung der Java-Parallelität] ----- Analyse der Volatilität des Java-Speichermodells

Die Eigenschaften von Volatile wurden bereits im vorherigen Blog [Fuck Java Concurrency] erläutert - Eingehende Analyse des Implementierungsprinzips von Volatile:

1. Volatile Visibility; Bei flüchtigen Lesevorgängen können Sie immer den endgültigen Schreibvorgang für diese Variable sehen. aber zusammengesetzt Mit Ausnahme von Operationen wie i++; Die Speichersemantik von volatile führt volatile in zwei Richtungen ein.

flüchtig und geschieht vorher

2. In diesem Blog [Tödliche Java-Parallelität] - Java-Speichermodell Happend-Before erklärt LZ, dass „happen-before“ verwendet wird, um zu bestimmen, ob Daten gespeichert werden Die Grundlage für Wettbewerb und Thread-Sicherheit besteht darin, die Sichtbarkeit in einer Multithread-Umgebung sicherzustellen. Nehmen wir das klassische Beispiel, um die durch das Lesen und Schreiben flüchtiger Variablen hergestellte Geschehen-vorher-Beziehung zu analysieren.

3. Gemäß dem „Passiert-vorher-Prinzip“ ergibt sich für das obige Programm die folgende Beziehung:

public class VolatileTest {

    int i = 0;    volatile boolean flag = false;    //Thread A
    public void write(){
        i = 2;              //1
        flag = true;        //2
    }    //Thread B
    public void read(){        if(flag){                                   //3
            System.out.println("---i = " + i);      //4
        }
    }
}

Operation 1 und Operation 4 haben eine „passiert-vorher“-Beziehung, daher muss 1 für 4 sichtbar sein. Einige Schüler fragen sich vielleicht: Operation 1 und Operation 2 können neu angeordnet werden. Ist das möglich? Wenn Sie den Blog von LZ gelesen haben, werden Sie verstehen, dass Volatilität nicht nur die Sichtbarkeit gewährleistet, sondern auch die Nachbestellung verbietet. Daher werden alle gemeinsam genutzten Variablen, die für Thread A vor dem Schreiben der flüchtigen Variablen sichtbar waren, für Thread B sofort sichtbar, nachdem Thread B dieselbe flüchtige Variable gelesen hat.

Speichersemantik und Implementierung von Volatile

• In JMM wird die Kommunikation zwischen Threads mithilfe von Shared Memory implementiert. Die Speichersemantik von flüchtig ist:

• Beim Schreiben einer flüchtigen Variablen aktualisiert JMM sofort den Wert der gemeinsam genutzten Variablen im lokalen Speicher, der dem Thread im Hauptspeicher entspricht.

  Beim Lesen einer flüchtigen Variablen setzt JMM den dem Thread entsprechenden lokalen Speicher auf ungültig und liest die gemeinsam genutzte Variable direkt aus dem Hauptspeicher

• Daher wird die Schreibspeichersemantik von flüchtig aktualisiert Der Hauptspeicher besteht darin, direkt aus dem Hauptspeicher zu lesen.

  Wie wird also die Semantik des flüchtigen Speichers implementiert? Bei allgemeinen Variablen werden sie neu angeordnet, bei flüchtigen Variablen jedoch nicht. Dies wirkt sich auf die Speichersemantik aus. Um eine flüchtige Speichersemantik zu erreichen, begrenzt JMM die Neuordnung. Die Neuordnungsregeln lauten wie folgt:

wird wie folgt übersetzt:

Wenn die erste Operation ein flüchtiger Lesevorgang ist, kann dies unabhängig von der zweiten Operation nicht der Fall sein nachbestellt. Diese Operation stellt sicher, dass Vorgänge nach dem flüchtigen Lesevorgang vom Compiler nicht auf vor dem flüchtigen Lesevorgang umgeordnet werden.

Wenn es sich bei der zweiten Operation um eine flüchtige Schreiboperation handelt, spielt es keine Rolle, um welche erste Operation es sich handelt , Beides kann nicht nachbestellt werden. Diese Operation stellt sicher, dass der Compiler Vorgänge vor dem flüchtigen Schreiben nicht in die Reihenfolge nach dem flüchtigen Schreiben umordnet.

Die zugrunde liegende Implementierung von volatile erfolgt durch das Einfügen von Speicherbarrieren, aber es ist für den Compiler fast unmöglich, eine optimale Anordnung zu finden, die die Gesamtzahl der eingefügten Speicherbarrieren minimiert, daher übernimmt JMM diese eine konservative Strategie. Wie folgt:

1. Fügen Sie vor jedem flüchtigen Schreibvorgang eine StoreStore-Barriere ein

2. Fügen Sie nach jedem flüchtigen Schreibvorgang eine StoreLoad-Barriere ein

3. Fügen Sie nach jedem flüchtigen Lesevorgang eine LoadLoad-Barriere ein

Fügen Sie nach jedem flüchtigen Lesevorgang eine LoadStore-Barriere ein

• StoreStore Barriere kann sicherstellen, dass alle normalen Schreibvorgänge vor dem flüchtigen Schreiben in den Hauptspeicher geleert werden.

Der Zweck der StoreLoad-Barriere besteht darin, zu verhindern, dass flüchtige Schreibvorgänge durch nachfolgende flüchtige Lese-/Schreibvorgänge neu angeordnet werden.

• Die LoadLoad-Barriere wird verwendet, um zu verhindern, dass der Prozessor den flüchtigen Lesevorgang oben und den normalen Lesevorgang unten neu anordnet.

Die LoadStore-Barriere wird verwendet, um zu verhindern, dass der Prozessor flüchtige Lesevorgänge oben und normale Schreibvorgänge unten neu anordnet.

• Lassen Sie uns das VolatileTest-Beispiel oben analysieren:

Die Legende zur Speicherbarriere der flüchtigen Anweisung wird anhand eines Beispiels leicht demonstriert.

Volatiles Speicherbarrieren-Einfügungsstrategie ist sehr konservativ. In der Praxis kann der Compiler entsprechend der spezifischen Situation optimieren und unnötige Barrieren weglassen, solange die Semantik des flüchtigen Schreib-Lese-Speichers nicht geändert wird. Wie folgt (Auszug aus Fang Tengfeis „The Art of Java Concurrent Programming“):

Lassen Sie uns das obige Bild analysieren. Welche Anweisungen zur Speicherbarriere überflüssig sind

public class VolatileTest {
    int i = 0;    
    volatile boolean flag = false;    
    public void write(){
        i = 2;
        flag = true;
    }    public void read(){        
    if(flag){
            System.out.println("---i = " + i); 
        }
    }
}

1: Diese muss beibehalten werden

2: Alle folgenden normalen Schreibvorgänge dürfen nicht mit den oben genannten flüchtigen Lesevorgängen neu angeordnet werden. Da jedoch ein zweiter flüchtiger Lesevorgang vorhanden ist, kann der normale Lesevorgang den zweiten flüchtigen Lesevorgang überhaupt nicht umgehen. Es kann also weggelassen werden.

3: Es gibt unten keine normale Lesart und kann weggelassen werden.

4: reserviert

5: reserviert

6: gefolgt von einem flüchtigen Schreibvorgang, Also kann

7 weggelassen werden: Behalte

8: Behalte

bei, damit 2, 3 und 6 weggelassen werden können, Sein schematisches Diagramm lautet wie folgt:

Das Obige ist der Inhalt von [Tödliche Java-Parallelität] ----- Analyse des Java-Speichers Modell Volatile, mehr Für verwandte Inhalte achten Sie bitte auf die chinesische PHP-Website (m.sbmmt.com)!