Analyse approfondie du modèle de mémoire Java : finale

Par rapport aux verrous et aux volatiles introduits précédemment, la lecture et l'écriture du champ final ressemblent davantage à un accès aux variables ordinaire. Pour les champs finaux, le compilateur et le processeur doivent respecter deux règles de réorganisation :
écrire un champ final dans le constructeur et attribuer ensuite une référence à l'objet construit à une variable de référence.
La première lecture d'une référence à un objet contenant un champ final et la première lecture ultérieure du champ final ne peuvent pas être réorganisées entre les deux opérations.

Ci-dessous, nous utilisons un exemple de code pour illustrer respectivement ces deux règles :

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域
    }
}

Ici, on suppose qu'un thread A exécute la méthodewriter (), puis un autre thread B exécute la méthode reader (). Ci-dessous, nous illustrons ces deux règles à travers l'interaction de ces deux fils.

Règles de réorganisation pour l'écriture des champs finaux

Les règles de réorganisation pour l'écriture des champs finaux interdisent la réorganisation de l'écriture des champs finaux en dehors du constructeur. L'implémentation de cette règle comprend les deux aspects suivants :
JMM interdit au compilateur de réordonner l'écriture des champs finaux en dehors du constructeur.
Le compilateur insérera une barrière StoreStore après avoir écrit le champ final et avant le retour du constructeur. Cette barrière empêche le processeur de réorganiser les écritures dans les champs finaux en dehors du constructeur.

Analysons maintenant la méthodewriter(). La méthodewriter() ne contient qu'une seule ligne de code : finalExample = new FinalExample(). Cette ligne de code contient deux étapes :
Construire un objet de type FinalExample
Asigner la référence de cet objet à la variable de référence obj ;

En supposant qu'il n'y a pas de réorganisation entre le thread B lisant la référence de l'objet et la lecture des champs membres de l'objet (j'expliquerai bientôt pourquoi cette hypothèse est nécessaire), la figure suivante est une séquence d'exécution possible :

Dans la figure ci-dessus, l'opération d'écriture dans le champ ordinaire a été réorganisée par le compilateur en dehors du constructeur, et le thread de lecture B a lu par erreur la valeur de la variable ordinaire i avant qu'elle ne soit initialisé. L'opération d'écriture du champ final est "limitée" au sein du constructeur par les règles de réorganisation de l'écriture du champ final, et le thread de lecture B lit correctement la valeur après l'initialisation de la variable finale.

L'écriture de règles de réorganisation pour les champs finaux peut garantir que le champ final de l'objet a été correctement initialisé avant que la référence de l'objet ne soit visible par n'importe quel thread, alors que les champs ordinaires n'ont pas cette garantie. En prenant la figure ci-dessus comme exemple, lorsque le thread de lecture B "voit" la référence d'objet obj, il est probable que l'objet obj n'a pas encore été construit (l'opération d'écriture dans le champ ordinaire i est réorganisée en dehors du constructeur, et le la valeur initiale 2 n'a pas encore été écrite) Domaine commun i).

Règles de réorganisation pour la lecture des champs finaux

Les règles de réorganisation pour la lecture des champs finaux sont les suivantes :
Dans un fil de discussion, la première fois que vous lisez une référence d'objet est la première fois que vous lisez le champ final contenu dans l'objet, JMM interdit au processeur de réordonner ces deux opérations (notez que cette règle s'applique uniquement au processeur). Le compilateur insère une barrière LoadLoad avant l'opération de lecture de champ finale.

Il existe une dépendance indirecte entre les deux opérations de lecture de la référence de l'objet pour la première fois et de lecture du champ final contenu dans l'objet pour la première fois. Puisque le compilateur respecte les dépendances indirectes, le compilateur ne réorganise pas ces deux opérations. La plupart des processeurs honoreront également les dépendances indirectes et ne réorganiseront pas ces deux opérations. Cependant, quelques processeurs autorisent la réorganisation des opérations avec des dépendances indirectes (comme les processeurs alpha), et cette règle est spécifiquement conçue pour ces processeurs.

La méthode reader() comprend trois opérations :
Première variable de référence de lecture obj ;
Variable de référence de première lecture obj pointe vers le domaine commun j de l'objet.
La variable de référence de lecture initiale obj pointe vers le champ final i de l'objet.

Nous supposons maintenant qu'aucune réorganisation ne se produit lors de l'écriture du thread A et que le programme est exécuté sur un processeur qui ne respecte pas les dépendances indirectes. Voici un timing d'exécution possible :

<🎜. >

Les règles de réorganisation pour la lecture des champs finaux garantissent qu'avant de lire le champ final d'un objet, la référence à l'objet contenant le champ final doit être lue en premier. Dans cet exemple de programme, si la référence n'est pas nulle, alors le champ final de l'objet référencé doit avoir été initialisé par le thread A.

Si le champ final est un type référence

Le champ final que nous avons vu ci-dessus est un type de données de base. Voyons quel sera l'effet si le champ final est un type référence ?

Veuillez consulter l'exemple de code suivant :

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中文网（m.sbmmt.com）！