Java 메모리 모델 심층 분석: 최종

앞서 소개한 잠금 및 휘발성과 비교하면 최종 필드를 읽고 쓰는 것은 일반적인 변수 액세스와 비슷합니다. final 필드의 경우 컴파일러와 프로세서는 두 가지 재정렬 규칙을 준수해야 합니다. 생성자 내에 최종 필드를 작성한 후 생성된 개체에 대한 참조를 참조 변수에 할당하는 작업은 재정렬될 수 없습니다. 최종 필드가 포함된 개체에 대한 참조의 첫 번째 읽기와 최종 필드의 후속 첫 번째 읽기는 두 작업 간에 재정렬될 수 없습니다. 아래에서는 몇 가지 예제 코드를 사용하여 이 두 가지 규칙을 각각 설명합니다. 여기에서는 한 스레드 A가writer() 메서드를 실행한 다음 다른 스레드 B가 실행한다고 가정합니다. 리더 () 메소드. 아래에서는 이 두 스레드의 상호 작용을 통해 이 두 규칙을 설명합니다. 최종 필드 작성 규칙 재정렬최종 필드 작성 규칙 재정렬은 생성자 외부에서 최종 필드 작성을 재정렬하는 것을 금지합니다. 이 규칙의 구현에는 다음 두 가지 측면이 포함됩니다. JMM은 컴파일러가 생성자 외부에서 최종 필드 쓰기 순서를 변경하는 것을 금지합니다. 컴파일러는 최종 필드를 작성한 후 생성자가 반환되기 전에 StoreStore 장벽을 삽입합니다. 이 장벽은 프로세서가 생성자 외부의 최종 필드에 대한 쓰기 순서를 변경하는 것을 방지합니다. 이제 작가() 방식을 분석해 보겠습니다. writer() 메서드에는 finalExample = new FinalExample()이라는 한 줄의 코드만 포함됩니다. 이 코드 줄에는 두 단계가 포함되어 있습니다. FinalExample 유형의 개체를 구성합니다. 이 개체의 참조를 참조 변수 obj에 할당합니다. 객체 참조를 읽는 스레드 B와 객체의 멤버 필드를 읽는 사이에 재정렬이 없다고 가정할 때(이 가정이 왜 필요한지 곧 설명하겠습니다), 다음 그림은 가능한 실행 순서입니다. 위 그림에서 일반 필드에 쓰는 작업은 생성자 외부의 컴파일러에 의해 재정렬되었으며 읽기 스레드 B는 실수로 일반 변수 i의 값을 읽기 전에 읽습니다. 초기화되었습니다. 최종 필드를 작성하는 작업은 최종 필드 작성의 재정렬 규칙에 따라 생성자 내에서 "제한"되며 읽기 스레드 B는 최종 변수가 초기화된 후 값을 올바르게 읽습니다. 최종 필드의 재정렬 규칙을 작성하면 객체 참조가 모든 스레드에 표시되기 전에 객체의 최종 필드가 올바르게 초기화되었는지 확인할 수 있지만 일반 필드에는 이러한 보장이 없습니다. 위 그림을 예로 들면, 읽기 스레드 B가 객체 참조 obj를 "인식"하면 obj 객체가 아직 생성되지 않았을 가능성이 높습니다(일반 필드 i에 대한 쓰기 작업은 생성자 외부에서 재정렬되고 초기값 2는 아직 작성되지 않았습니다) 공통 도메인 i). 최종 필드 읽기 규칙 재정렬최종 필드 읽기 재정렬 규칙은 다음과 같습니다. 스레드에서 객체 참조를 처음 읽을 때 마지막 필드를 처음 읽을 때와 같습니다. 객체에 포함되어 있으면 JMM은 프로세서가 이 두 작업의 순서를 변경하는 것을 금지합니다(이 규칙은 프로세서에만 적용된다는 점에 유의하세요). 컴파일러는 최종 필드를 읽는 작업 전에 LoadLoad 장벽을 삽입합니다. 객체 참조를 처음으로 읽는 작업과 객체에 포함된 최종 필드를 처음으로 읽는 두 작업 사이에는 간접적인 종속성이 있습니다. 컴파일러는 간접 종속성을 존중하므로 컴파일러는 이 두 작업의 순서를 바꾸지 않습니다. 대부분의 프로세서는 간접적인 종속성도 존중하며 대부분의 프로세서는 이 두 작업의 순서를 바꾸지 않습니다. 그러나 일부 프로세서에서는 간접 종속성(예: 알파 프로세서)이 있는 작업 재정렬을 허용하며 이 규칙은 그러한 프로세서를 위해 특별히 설계되었습니다. reader() 메서드에는 세 가지 작업이 포함됩니다. 첫 번째 읽기 참조 변수 obj;첫 번째 읽기 참조 변수 obj는 객체의 공통 도메인 j를 가리킵니다. 초기 읽기 참조 변수 obj는 객체의 최종 필드 i를 가리킵니다. 이제 스레드 A 작성 시 재정렬이 발생하지 않고 간접 종속성을 준수하지 않는 프로세서에서 프로그램이 실행된다고 가정합니다. 가능한 실행 타이밍은 다음과 같습니다. 위 그림에서 객체의 일반 필드를 읽는 작업은 객체 참조를 읽기 전에 프로세서에 의해 재정렬됩니다. 공통 필드를 읽을 때 스레드 A를 작성하여 해당 필드를 쓰지 않았습니다. 이는 잘못된 읽기 작업입니다. 최종 필드를 읽기 위한 재정렬 규칙은 객체 참조를 읽은 후 객체의 최종 필드를 읽는 작업을 "제한"합니다. 이때 최종 필드는 올바른 읽기 작업인 A 스레드에 의해 초기화되었습니다. 최종 필드 읽기에 대한 재정렬 규칙은 객체의 마지막 필드를 읽기 전에 최종 필드를 포함하는 객체에 대한 참조를 먼저 읽어야 함을 보장합니다. 이 예제 프로그램에서 참조가 null이 아닌 경우 참조된 개체의 최종 필드는 스레드 A에 의해 초기화되어야 합니다. 최종 필드가 참조 유형인 경우위에서 본 마지막 필드가 기본 데이터 유형인 경우 마지막 필드가 참조 유형인 경우 어떤 효과가 있는지 살펴보겠습니다. 다음 샘플 코드를 참조하세요.

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）！