Java メモリモデルの詳細な分析: 最終版-＆＃＆チュートリアル-php.cn

前に紹介したロックや揮発性と比較すると、最終フィールドの読み書きは通常の変数アクセスに似ています。 Final フィールドの場合、コンパイラとプロセッサは 2 つの並べ替え規則に従う必要があります。コンストラクター内で Final フィールドを書き込み、その後構築されたオブジェクトへの参照を参照変数に割り当てることはできません。
最終フィールドを含むオブジェクトへの参照の最初の読み取りと、それに続く最終フィールドの最初の読み取りは、これら 2 つの操作の間で順序を変更できません。

以下では、いくつかのコード例を使用してこれら 2 つのルールをそれぞれ説明します:

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

ログイン後にコピー

1 つのスレッド A が Writer () メソッドを実行し、次に別のスレッド B が Reader () メソッドを実行すると仮定します。以下では、これら 2 つのスレッドの相互作用を通じてこれら 2 つのルールを説明します。

最終フィールドの書き込みの並べ替えルール

最終フィールドの書き込みの並べ替えルールでは、コンストラクター外での最終フィールドの書き込みの並べ替えを禁止します。このルールの実装には、次の 2 つの側面が含まれます:
JMM は、コンパイラーがコンストラクター外の最終フィールドの書き込みを並べ替えることを禁止します。
コンパイラーは、最後のフィールドを書き込んだ後、コンストラクターが戻る前に StoreStore バリアを挿入します。このバリアにより、プロセッサがコンストラクター外の最終フィールドへの書き込みの順序を変更することができなくなります。

それでは、writer() メソッドを分析してみましょう。 Writer () メソッドには、finalExample = new FinalExample () という 1 行のコードのみが含まれています。このコード行には 2 つのステップが含まれています:
FinalExample 型のオブジェクトを構築します。
このオブジェクトの参照を参照変数 obj に割り当てます。

スレッド B によるオブジェクト参照の読み取りとオブジェクトのメンバーフィールドの読み取りの間に順序変更がないと仮定すると (この仮定が必要な理由についてはすぐに説明します)、次の図は考えられる実行シーケンスです。 Figure, write 通常のフィールドの操作がコンストラクターの外でコンパイラによって並べ替えられ、読み取りスレッド B が初期化される前に通常の変数 i の値を誤って読み取りました。最終フィールドを書き込む操作は、最終フィールドを書き込む並べ替えルールによってコンストラクター内で「制限」され、読み取りスレッド B は最終変数が初期化された後に値を正しく読み取ります。

final フィールドの並べ替えルールを記述すると、オブジェクト参照がスレッドに表示される前に、オブジェクトの Final フィールドが正しく初期化されていることを保証できますが、通常のフィールドにはこの保証がありません。上の図を例にとると、読み取りスレッド B が obj を参照するオブジェクトを「認識」したとき、obj オブジェクトはまだ構築されていない可能性が非常に高くなります (通常のフィールド i への書き込み操作はコンストラクターの外側で並べ替えられます)。初期値 2 はまだ書き込まれていません) 共通ドメイン i)。

Java メモリモデルの詳細な分析: 最終版最終フィールドを読み取るための並べ替え規則

最終フィールドを読み取るための並べ替え規則は次のとおりです:
スレッド内で、初めてオブジェクト参照を読み取るとき、およびオブジェクトに含まれる最終フィールドを初めて読み取るとき、JMM はプロセッサーが次のことを行うことを禁止します。これら 2 つの操作の順序を変更します (このルールはプロセッサーにのみ適用されることに注意してください)。コンパイラは、最後のフィールド読み取り操作の前に LoadLoad バリアを挿入します。

初めてオブジェクト参照を読み取る操作と、オブジェクトに含まれる最終フィールドを初めて読み取るという 2 つの操作の間には間接的な依存関係があります。コンパイラは間接的な依存関係を考慮するため、これら 2 つの操作の順序を変更しません。ほとんどのプロセッサは間接的な依存関係も尊重し、これら 2 つの操作の順序を変更しません。ただし、一部のプロセッサでは間接的な依存関係を持つ操作の並べ替えが許可されており (アルファプロセッサなど)、このルールはそのようなプロセッサ向けに特別に設計されています。

reader() メソッドには 3 つの操作が含まれています:
最初の読み取り参照変数 obj;
最初の読み取り参照変数 obj は、オブジェクトの通常のドメイン j を指します。
最初に読み取られた参照変数 obj は、オブジェクトの最後のフィールド i を指します。

ここで、スレッド A の書き込み中に並べ替えが発生せず、プログラムが間接的な依存関係に準拠しないプロセッサ上で実行されると仮定します。考えられる実行シーケンスは次のとおりです。

上の図では、通常のオブジェクトの読み取りドメイン操作は、オブジェクト参照を読み取る前にプロセッサによって並べ替えられます。共通フィールドを読み取るとき、そのフィールドは書き込みスレッド A によって書き込まれていません。これは不正な読み取り操作です。最終フィールドを読み取るための並べ替え規則により、オブジェクト参照の読み取り後にオブジェクトの最終フィールドを読み取る操作が「制限」されます。この時点で、最終フィールドは A スレッドによって初期化されており、これは正しい読み取り操作です。

最終フィールドを読み取るための並べ替えルールにより、オブジェクトの最終フィールドを読み取る前に、最終フィールドを含むオブジェクトへの参照が最初に読み取られる必要があります。このサンプルプログラムでは、参照が null でない場合、参照されるオブジェクトの最後のフィールドはスレッド A によって初期化されている必要があります。

Java メモリモデルの詳細な分析: 最終版最後のフィールドが参照型の場合

上で見た最後のフィールドは、基本的なデータ型です。最後のフィールドが参照型の場合にどのような影響があるかを見てみましょう。

次のサンプルコードをご覧ください:

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 ()方法。下面是一种可能的线程执行时序：

Java メモリモデルの詳細な分析: 最終版

在上图中，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之间可能被重排序。实际的执行时序可能如下图所示：

Java メモリモデルの詳細な分析: 最終版

从上图我们可以看出：在构造函数返回前，被构造对象的引用不能为其他线程可见，因为此时的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）！