Heim > Artikel > Java > Eingehende Analyse des Java-Speichermodells: flüchtig

Eingehende Analyse des Java-Speichermodells: flüchtig

黄舟Original: 2016-12-29 11:52:441255Durchsuche

Eigenschaften von Volatilität

Wenn wir eine gemeinsam genutzte Variable als Volatilität deklarieren, ist das Lesen/Schreiben dieser Variablen etwas ganz Besonderes. Eine gute Möglichkeit, die Natur von flüchtigen Variablen zu verstehen, besteht darin, sich einzelne Lese-/Schreibvorgänge auf flüchtige Variablen als Synchronisierung dieser einzelnen Lese-/Schreibvorgänge unter Verwendung derselben Monitorsperre vorzustellen. Lassen Sie uns dies anhand eines konkreten Beispiels veranschaulichen:

class VolatileFeaturesExample {
    volatile long vl = 0L;  //使用volatile声明64位的long型变量

    public void set(long l) {
        vl = l;   //单个volatile变量的写
    }

    public void getAndIncrement () {
        vl++;    //复合（多个）volatile变量的读/写
    }

    public long get() {
        return vl;   //单个volatile变量的读
    }
}

Angenommen, es gibt mehrere Threads, die die drei Methoden des oben genannten Programms aufrufen. Dieses Programm entspricht semantisch dem folgenden Programm:

class VolatileFeaturesExample {
    long vl = 0L;               // 64位的long型普通变量

    public synchronized void set(long l) {     //对单个的普通 变量的写用同一个监视器同步
        vl = l;
    }

    public void getAndIncrement () { //普通方法调用
        long temp = get();           //调用已同步的读方法
        temp += 1L;                  //普通写操作
        set(temp);                   //调用已同步的写方法
    }
    public synchronized long get() { 
    //对单个的普通变量的读用同一个监视器同步
        return vl;
    }
}

Wie im obigen Beispielprogramm gezeigt, verwendet ein einzelner Lese-/Schreibvorgang für eine flüchtige Variable dieselbe Monitorsperre wie ein Lese-/Schreibvorgang für eine gewöhnliche Variable Synchronized. Der Ausführungseffekt zwischen ihnen ist der gleiche.

Die Regel „Passiert vor“ der Monitorsperre gewährleistet die Speichersichtbarkeit zwischen den beiden Threads, die den Monitor freigeben und den Monitor abrufen. Dies bedeutet, dass ein Lesevorgang einer flüchtigen Variablen immer (jeder Thread) beim endgültigen Schreiben sichtbar ist zu dieser flüchtigen Variablen.

Die Semantik von Monitorsperren bestimmt, dass die Ausführung des Codes kritischer Abschnitte atomar ist. Dies bedeutet, dass selbst bei 64-Bit-langen und doppelten Variablen das Lesen und Schreiben in die Variable atomar ist, solange es sich um eine flüchtige Variable handelt. Wenn es mehrere flüchtige Operationen oder zusammengesetzte Operationen wie volatile++ gibt, sind diese Operationen als Ganzes nicht atomar.

Kurz gesagt, flüchtige Variablen selbst haben die folgenden Eigenschaften:
Sichtbarkeit. Bei einem Lesevorgang aus einer flüchtigen Variablen wird immer der letzte Schreibvorgang (durch einen beliebigen Thread) in die flüchtige Variable angezeigt.
Atomizität: Das Lesen/Schreiben einer einzelnen flüchtigen Variablen ist atomar, aber zusammengesetzte Operationen wie volatile++ sind nicht atomar.

Die Beziehung geschieht vor dem Aufbau der flüchtigen Schreib-/Lesebeziehung

Oben geht es um die Eigenschaften flüchtiger Variablen selbst. Für Programmierer hat flüchtig einen größeren Einfluss auf die Speichersichtbarkeit von Threads als flüchtig selbst . Funktionen sind wichtiger und erfordern mehr Aufmerksamkeit von uns.

Ab JSR-133 ermöglicht das Schreiben/Lesen flüchtiger Variablen die Kommunikation zwischen Threads.

Aus Sicht der Speichersemantik haben flüchtige Sperren und Monitorsperren den gleichen Effekt: flüchtiges Schreiben und Monitorfreigabe haben dieselbe Speichersemantik; flüchtiges Lesen und Monitorerfassung haben dieselbe Speichersemantik.

Bitte sehen Sie sich den folgenden Beispielcode an, der flüchtige Variablen verwendet:

class VolatileExample {
    int a = 0;
    volatile boolean flag = false;

    public void writer() {
        a = 1;                   //1
        flag = true;               //2
    }

    public void reader() {
        if (flag) {                //3
            int i =  a;           //4
            ……
        }
    }
}

Angenommen, nachdem Thread A die Writer()-Methode ausgeführt hat, führt Thread B die Reader()-Methode aus. Gemäß der Regel „passiert vor“ kann die in diesem Prozess hergestellte Beziehung „passiert vor“ in zwei Kategorien unterteilt werden:
Gemäß der Regel für die Programmreihenfolge geschieht 1 vor 2;
Gemäß den Volatilitätsregeln passiert 2 vor 3.
Gemäß der Transitivitätsregel passiert 1 vor 4.

Die grafische Darstellung der oben genannten „Schiebt vor“-Beziehung sieht wie folgt aus: