Eingehende Analyse des Java-Speichermodells: endgültig

Im Vergleich zu den zuvor eingeführten Sperren und flüchtigen Elementen ähneln das Lesen und Schreiben des letzten Felds eher dem normalen Variablenzugriff. Für endgültige Felder müssen der Compiler und der Prozessor zwei Neuordnungsregeln einhalten:
Schreiben eines endgültigen Felds innerhalb des Konstruktors und anschließendes Zuweisen einer Referenz auf das konstruierte Objekt zu einer Referenzvariablen. Operationen können nicht neu angeordnet werden.
Das erste Lesen einer Referenz auf ein Objekt, das ein letztes Feld enthält, und das anschließende erste Lesen des letzten Felds können zwischen den beiden Vorgängen nicht neu angeordnet werden.

Im Folgenden verwenden wir einen Beispielcode, um diese beiden Regeln zu veranschaulichen:

public class FinalExample {
    int i;                            //普通变量
    final int j;                      //final变量
    static FinalExample obj;

    public void FinalExample () {     //构造函数
        i = 1;                        //写普通域
        j = 2;                        //写final域
    }

    public static void writer () {    //写线程A执行
        obj = new FinalExample ();
    }

    public static void reader () {       //读线程B执行
        FinalExample object = obj;       //读对象引用
        int a = object.i;                //读普通域
        int b = object.j;                //读final域
    }
}

Hier wird angenommen, dass ein Thread A die Writer()-Methode ausführt und dann ein anderer Thread B die read()-Methode. Im Folgenden veranschaulichen wir diese beiden Regeln anhand der Interaktion dieser beiden Threads.

Neuordnungsregeln für das Schreiben von Endfeldern

Neuordnungsregeln für das Schreiben von Endfeldern verhindern das Neuordnen des Schreibens von Endfeldern außerhalb des Konstruktors. Die Implementierung dieser Regel umfasst die folgenden zwei Aspekte:
JMM verhindert, dass der Compiler die Schreibvorgänge des endgültigen Felds außerhalb des Konstruktors neu anordnet.
Der Compiler fügt nach dem Schreiben des letzten Felds und vor der Rückkehr des Konstruktors eine StoreStore-Barriere ein. Diese Barriere verhindert, dass der Prozessor Schreibvorgänge in endgültige Felder außerhalb des Konstruktors neu anordnet.

Lassen Sie uns nun die Writer()-Methode analysieren. Die Methode write() enthält nur eine Codezeile: finalExample = new FinalExample(). Diese Codezeile enthält zwei Schritte:
Konstruieren Sie ein Objekt vom Typ FinalExample;
Weisen Sie die Referenz dieses Objekts der Referenzvariablen obj zu.

Unter der Annahme, dass es keine Neuordnung zwischen dem Lesen der Objektreferenz durch Thread B und dem Lesen der Mitgliedsfelder des Objekts gibt (ich werde bald erklären, warum diese Annahme erforderlich ist), ist die folgende Abbildung eine mögliche Ausführungssequenz:

In der obigen Abbildung wurde der Vorgang des Schreibens in das gewöhnliche Feld vom Compiler außerhalb des Konstruktors neu angeordnet, und der Lesethread B hat fälschlicherweise den Wert der gewöhnlichen Variablen i gelesen, bevor er war initialisiert. Der Vorgang des Schreibens des letzten Felds ist innerhalb des Konstruktors durch die Neuordnungsregeln des Schreibens des letzten Felds „begrenzt“, und der Lesethread B liest den Wert korrekt, nachdem die letzte Variable initialisiert wurde.

Das Schreiben von Neuordnungsregeln für Endfelder kann sicherstellen, dass das Endfeld des Objekts korrekt initialisiert wurde, bevor die Objektreferenz für jeden Thread sichtbar ist, während für normale Felder diese Garantie nicht gilt. Nehmen wir die obige Abbildung als Beispiel: Wenn der Lesethread B das Objekt „sieht“, das auf obj verweist, ist es sehr wahrscheinlich, dass das obj-Objekt noch nicht erstellt wurde (der Schreibvorgang in das gewöhnliche Feld i wird außerhalb des Konstruktors neu angeordnet). der Anfangswert 2 wurde noch nicht geschrieben) Gemeinsamer Bereich i).

Neuordnungsregeln für das Lesen von Endfeldern

Neuordnungsregeln für das Lesen von Endfeldern lauten wie folgt:
In einem Thread ist das erste Lesen einer Objektreferenz das erste Mal, dass das Endfeld gelesen wird Im Objekt enthalten ist, verbietet JMM dem Prozessor, diese beiden Vorgänge neu anzuordnen (beachten Sie, dass diese Regel nur für den Prozessor gilt). Der Compiler fügt vor dem letzten Feldlesevorgang eine LoadLoad-Barriere ein.

Es besteht eine indirekte Abhängigkeit zwischen den beiden Vorgängen des ersten Lesens der Objektreferenz und des ersten Lesens des im Objekt enthaltenen endgültigen Felds. Da der Compiler indirekte Abhängigkeiten berücksichtigt, ordnet er diese beiden Vorgänge nicht neu an. Die meisten Prozessoren berücksichtigen auch indirekte Abhängigkeiten und ordnen diese beiden Vorgänge nicht neu an. Einige Prozessoren erlauben jedoch Neuordnungsvorgänge mit indirekten Abhängigkeiten (z. B. Alpha-Prozessoren), und diese Regel wurde speziell für solche Prozessoren entwickelt.

Die Methode read() umfasst drei Operationen:
Erstes Lesen der Referenzvariable obj;
Erstes Lesen der Referenzvariable obj zeigt auf die gemeinsame Domäne j des Objekts.
Die anfängliche Lesereferenzvariable obj zeigt auf das letzte Feld i des Objekts.

Jetzt gehen wir davon aus, dass beim Schreiben von Thread A keine Neuordnung erfolgt und das Programm auf einem Prozessor ausgeführt wird, der indirekte Abhängigkeiten nicht berücksichtigt. Das Folgende ist ein möglicher Ausführungszeitpunkt:

In der obigen Abbildung wird der Vorgang des Lesens des gewöhnlichen Felds des Objekts vom Prozessor neu angeordnet, bevor die Objektreferenz gelesen wird. Beim Lesen eines gemeinsamen Felds wurde das Feld nicht vom Schreibthread A geschrieben. Dies ist ein fehlerhafter Lesevorgang. Die Neuordnungsregeln zum Lesen des letzten Felds „beschränken“ den Vorgang des Lesens des letzten Felds des Objekts auf nach dem Lesen der Objektreferenz. Zu diesem Zeitpunkt wurde das letzte Feld vom A-Thread initialisiert, was ein korrekter Lesevorgang ist.

Die Neuordnungsregeln für das Lesen von Endfeldern stellen sicher, dass vor dem Lesen des Endfelds eines Objekts zuerst der Verweis auf das Objekt gelesen werden muss, das das Endfeld enthält. Wenn in diesem Beispielprogramm die Referenz nicht null ist, muss das letzte Feld des referenzierten Objekts von Thread A initialisiert worden sein.

Wenn das letzte Feld ein Referenztyp ist

Das letzte Feld, das wir oben gesehen haben, ist ein Basisdatentyp. Lassen Sie uns sehen, welche Auswirkungen es hat, wenn das letzte Feld ein Referenztyp ist.

Bitte sehen Sie sich den folgenden Beispielcode an:

public class FinalReferenceExample {
final int[] intArray;                     //final是引用类型
static FinalReferenceExample obj;

public FinalReferenceExample () {        //构造函数
    intArray = new int[1];              //1
    intArray[0] = 1;                   //2
}

public static void writerOne () {          //写线程A执行
    obj = new FinalReferenceExample ();  //3
}

public static void writerTwo () {          //写线程B执行
    obj.intArray[0] = 2;                 //4
}

public static void reader () {              //读线程C执行
    if (obj != null) {                    //5
        int temp1 = obj.intArray[0];       //6
    }
}
}

这里final域为一个引用类型，它引用一个int型的数组对象。对于引用类型，写final域的重排序规则对编译器和处理器增加了如下约束：
在构造函数内对一个final引用的对象的成员域的写入，与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

对上面的示例程序，我们假设首先线程A执行writerOne()方法，执行完后线程B执行writerTwo()方法，执行完后线程C执行reader ()方法。下面是一种可能的线程执行时序：

在上图中，1是对final域的写入，2是对这个final域引用的对象的成员域的写入，3是把被构造的对象的引用赋值给某个引用变量。这里除了前面提到的1不能和3重排序外，2和3也不能重排序。

JMM可以确保读线程C至少能看到写线程A在构造函数中对final引用对象的成员域的写入。即C至少能看到数组下标0的值为1。而写线程B对数组元素的写入，读线程C可能看的到，也可能看不到。JMM不保证线程B的写入对读线程C可见，因为写线程B和读线程C之间存在数据竞争，此时的执行结果不可预知。

如果想要确保读线程C看到写线程B对数组元素的写入，写线程B和读线程C之间需要使用同步原语（lock或volatile）来确保内存可见性。

为什么final引用不能从构造函数内“逸出”

前面我们提到过，写final域的重排序规则可以确保：在引用变量为任意线程可见之前，该引用变量指向的对象的final域已经在构造函数中被正确初始化过了。其实要得到这个效果，还需要一个保证：在构造函数内部，不能让这个被构造对象的引用为其他线程可见，也就是对象引用不能在构造函数中“逸出”。为了说明问题，让我们来看下面示例代码：

public class FinalReferenceEscapeExample {
final int i;
static FinalReferenceEscapeExample obj;

public FinalReferenceEscapeExample () {
    i = 1;                              //1写final域
    obj = this;                          //2 this引用在此“逸出”
}

public static void writer() {
    new FinalReferenceEscapeExample ();
}

public static void reader {
    if (obj != null) {                     //3
        int temp = obj.i;                 //4
    }
}
}

假设一个线程A执行writer()方法，另一个线程B执行reader()方法。这里的操作2使得对象还未完成构造前就为线程B可见。即使这里的操作2是构造函数的最后一步，且即使在程序中操作2排在操作1后面，执行read()方法的线程仍然可能无法看到final域被初始化后的值，因为这里的操作1和操作2之间可能被重排序。实际的执行时序可能如下图所示：

从上图我们可以看出：在构造函数返回前，被构造对象的引用不能为其他线程可见，因为此时的final域可能还没有被初始化。在构造函数返回后，任意线程都将保证能看到final域正确初始化之后的值。

final语义在处理器中的实现

现在我们以x86处理器为例，说明final语义在处理器中的具体实现。

上面我们提到，写final域的重排序规则会要求译编器在final域的写之后，构造函数return之前，插入一个StoreStore障屏。读final域的重排序规则要求编译器在读final域的操作前面插入一个LoadLoad屏障。

由于x86处理器不会对写-写操作做重排序，所以在x86处理器中，写final域需要的StoreStore障屏会被省略掉。同样，由于x86处理器不会对存在间接依赖关系的操作做重排序，所以在x86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说在x86处理器中，final域的读/写不会插入任何内存屏障！

JSR-133为什么要增强final的语义

在旧的Java内存模型中 ，最严重的一个缺陷就是线程可能看到final域的值会改变。比如，一个线程当前看到一个整形final域的值为0（还未初始化之前的默认值），过一段时间之后这个线程再去读这个final域的值时，却发现值变为了1（被某个线程初始化之后的值）。最常见的例子就是在旧的Java内存模型中，String的值可能会改变（参考文献2中有一个具体的例子，感兴趣的读者可以自行参考，这里就不赘述了）。

为了修补这个漏洞，JSR-133专家组增强了final的语义。通过为final域增加写和读重排序规则，可以为java程序员提供初始化安全保证：只要对象是正确构造的（被构造对象的引用在构造函数中没有“逸出”），那么不需要使用同步（指lock和volatile的使用），就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。

 以上就是Java内存模型深度解析：final的内容，更多相关内容请关注PHP中文网（www.php.cn）！