Beispielanalyse des flüchtigen und JMM-Multithread-Speichermodells in der gleichzeitigen Java-Programmierung

1. Sehen Sie sich das Phänomen durch das Programm an

Bevor wir beginnen, Ihnen das Java-Multithread-Cache-Modell zu erklären, schauen wir uns zunächst den folgenden Code an. Die Logik dieses Codes ist sehr einfach: Der Hauptthread startet zwei Unterthreads, einen Thread 1 und einen Thread 2. Thread 1 wird zuerst ausgeführt und Thread 2 wird nach 2 Sekunden Ruhezustand ausgeführt. Die beiden Threads verwenden eine gemeinsam genutzte Variable shareFlag mit dem Anfangswert false. Wenn shareFlag immer gleich false ist, befindet sich Thread 1 immer in einer Endlosschleife, daher setzen wir shareFlag in Thread 2 auf true.

public class VolatileTest {
  public static boolean shareFlag = false;
  public static void main(String[] args) throws InterruptedException {
    new Thread(() -> {
      System.out.print("开始执行线程1 =>");
      while (!shareFlag){  //shareFlag = false则一直死循环
        //System.out.println("shareFlag=" + shareFlag);
      }
      System.out.print("线程1执行完成 =>");
    }).start();
    Thread.sleep(2000);
    new Thread(() -> {
      System.out.print("开始执行线程2 =>");
      shareFlag = true;
      System.out.print("线程2执行完成 =>");
    }).start();
  }
}

Wenn Sie das JMM-Thread-Modell nicht gelernt haben, hoffen Sie vielleicht nach dem Lesen des obigen Codes, dass das Ausgabeergebnis wie folgt lautet:

Starten Sie die Ausführung von Thread 1 => Starten Sie die Ausführung von Thread 2 => Ausführung von Thread 2 abgeschlossen = > Ausführung von Thread 1 abgeschlossen =>

Wie in der Abbildung unten gezeigt, verstehen normale Menschen diesen Code. Zuerst wird Thread 1 ausgeführt, um in die Schleife einzutreten, Thread 2 ändert shareFlag=true und Thread 1 springt aus der Schleife. Daher gibt Thread 1, der aus der Schleife ausbricht, „Thread 1-Ausführung abgeschlossen =>“ aus, aber nach dem Experiment des Autors wird **„Thread 1-Ausführung abgeschlossen =>“ nicht gedruckt und Thread 1 bricht nicht aus die Endlosschleife**.

2. Warum tritt dieses Phänomen auf (JMM-Modell)?

Um die oben genannten Probleme zu erklären, müssen wir das Java-Speichermodell JMM (Java Memory Model) lernen. Ich denke, es ist genauer, es Java-Multithread-Speichermodell zu nennen.

• Zuallererst hat in JMM jeder Thread seinen eigenen Arbeitsspeicher. Wenn das Programm startet, lädt (lesen und laden) der Thread gemeinsam genutzte Variablen in seinen eigenen Arbeitsspeicher, lädt in den Arbeitsspeicher des Threads sind Kopien von gemeinsam genutzten Variablen im Hauptspeicher. Das heißt, zu diesem Zeitpunkt befinden sich drei Kopien von shareFlag im Speicher, und ihre Werte sind alle gleich false.

• Wenn Thread 2 shareFlag=true ausführt, ändert er seine Arbeitsspeicherkopie in shareFlag=true und schreibt gleichzeitig den Wert der Kopie zurück (Speichern und Schreiben). im Hauptspeicher. shareFlag=true的时候将其工作内存副本修改为shareFlag=true，同时将副本的值同步写回(store&write)到主内存中。

• 但是线程1的工作内存中的shareFlag=false

Aber der

shareFlag=false

im Arbeitsspeicher von Thread 1 hat sich nicht geändert, sodass sich Thread 1 in einer Endlosschleife befand

.

3. MESI-Cache-Kohärenzprotokoll

Die Änderung gemeinsamer Variablen durch Thread 2 wird von Thread 1 nicht wahrgenommen, was mit den obigen experimentellen Ergebnissen und dem JMM-Modell übereinstimmt. Wie kann Thread 1 also erkennen, dass sich der Wert der gemeinsam genutzten Variablen geändert hat? Tatsächlich ist es sehr einfach, das Schlüsselwort volatile zur gemeinsam genutzten Variablen shareFlag hinzuzufügen.

public volatile static boolean shareFlag = false;

1. Das zugrunde liegende Prinzip ist wie folgt: Das Hinzufügen des Schlüsselworts volatile fordert JMM auf, dem MESI-Cache-Konsistenzprotokoll zu folgen, das die folgenden Cache-Nutzungsspezifikationen enthält (

   Wenn Sie es nicht verstehen, können Sie es ignorieren. Es wird in beschrieben einfache Sprache und Beispiele unten.

2. Geändert

   : Zeigt an, dass die Daten der aktuellen Cache-Zeile geändert (Dirty) sind und sich zu diesem Zeitpunkt nur im Cache der aktuellen CPU befinden. Die Daten der Cache-Zeile unterscheiden sich von den Daten in anderen Caches unterscheidet es sich auch von den Daten im Speicher für diese Zeile.

3. Exklusiv

   : Zeigt an, dass es sich bei den Daten in der aktuellen Cache-Zeile um gültige Daten handelt und es keine solche Datenzeile im Cache anderer CPUs gibt und die Daten der aktuellen Cache-Zeile mit den Daten im Speicher identisch sind .

4. Geteilt

   : Dies bedeutet, dass diese Datenzeile im Cache mehrerer CPUs zwischengespeichert wird und die Daten im Cache mit den Daten im Speicher übereinstimmen

Ungültig

: Das bedeutet dass die Daten in der aktuellen Cache-Zeile ungültig sind;

• Die oben genannten Cache-Nutzungsspezifikationen sind möglicherweise zu kompliziert:

• Wenn Thread 2 ShareFlag ändert (siehe Ändern), informieren Sie den Bus, dass ich die gemeinsam genutzte Variable shareFlag geändert habe,

• Thread 1 überwacht den Bus. Wenn er erfährt, dass die gemeinsam genutzte Variable shareFlag geändert wurde, löscht er die Kopie von shareFlag in seinem Arbeitsspeicher, um sie ungültig zu machen.

🎜Wenn Thread 1 ShareFlag erneut verwenden muss und feststellt, dass keine Kopie der ShareFlag-Variable im Arbeitsspeicher vorhanden ist, wird er aus dem Hauptspeicher neu geladen (lesen und laden)🎜🎜🎜

Das obige ist der detaillierte Inhalt vonBeispielanalyse des flüchtigen und JMM-Multithread-Speichermodells in der gleichzeitigen Java-Programmierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!