java多线程之final原理

final域的重排序规则

对于final的变量，编译器和处理器遵循两个排序规则：

1. 在构造函数内对一个final变量的写入，与随后把这个构造出来的变量的引用赋值给一个引用变量，这两个操作不能重排序。
2. 初次读一个包含final的变量的对象的引用，与随后初次读这个final域，这两个操作不能重排序。

通过几个例子来理解一下：

public class FinalExample {
    int i;
    final int j;
    static FinalExample obj;

    public 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变量
    }
}

这里假设线程A执行writer方法，随后线程B执行reader()方法。

写final变量的重排序规则

也就是对应的第一个重排序规则：“在构造函数内对一个final变量的写入，与随后把这个构造出来的变量的引用赋值给一个引用变量，这两个操作不能重排序”。

该规则是这样实现的：

编译器会在fianl变量的写之后，构造函数return之前(构造函数最后有个隐藏的return)，插入一个StoreStore屏障。因为该屏障，所以不会让final的写重排序到外面去，实现了fianl值的唯一性。

有些处理器是允许StoreStore这样的重排序的。

 如上图：构造函数中i=1这个操作被重排序到了构造函数赋值引用的后面去了，所以当线程B读取i的时候，可能会读取到一个未被初始化的值，而final变量是不会被排序到外面的，所以在对象引用为任意线程可见之前final域已经被正确的初始化了。

读final变量的重排序规则

对应“初次读一个包含final的变量的对象的引用，与随后初次读这个final域，这两个操作不能重排序”这条规则，编译器会在读一个final域操作的前面加上LoadLoad屏障。

因为初次读对象引用与初次读该对象包含的final域存在间接依赖关系，所以大部分处理器不会重排序，此节是针对那些少量的处理器。

现在假设写线程A没有任何的重排序，且程序在会对存在间接依赖关系的处理器中执行。可能的执行时序为：

 如上：把读普通域排序到了读独享的引用前面了，所以该读取操作是错误的；而读final域的重排序规则会将final域的读取限定在初次读对象引用之后，也就确保了fianl域的正确读取操作。

final域为引用对象

public class FinalExample {
    final int[] array;
    static FinalExample obj;

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

    public static void writer1() {//写线程A执行
        obj = new FinalExample();   //3
    }  
    public static void writer2() {//写线程B执行
        obj.array[0] = 2;     //4
    }
    
    public static void reader() { //读线程C执行
        if (obj != null){  //5
            int temp = obj.array[0];  //6
        }
    }
}

假设如上代码：A执行writer1方法，执行完后线程B执行writer2方法，完后线程C执行reader方法。

本例的final域为一个引用对象，对应引用类型，写final域的重排序规则对前面说过了多增加了一个：在构造函数内对一个final引用对象的成员进行写入的操作，与随后在构造函数外把这个构造出来的对象赋值给一个引用变量，这两个操作不能重排序。

解释：如上代码，除了前面所说的操作1和操作3不能重排序外，操作2和操作3也不能重排序。

线程C是一定能够知道线程A在构造函数中对final引用对象的成员域的写入，知道数组下标0的值为1。但是线程C不一定知道线程B对该成员域的写入，因为它不是构造函数中的写入，线程C和线程B之间存在数据竞争，执行结果不可预知。

如果想让线程C知道线程B对数组元素的写入，需要使用同步原语来确保内存可见性。

final引用不能从构造函数中溢出

前面说过的读final变量是说过：在对象引用为任意线程可见之前final域已经被正确的初始化了，这句话的前提是构造函数中，不能让这个被构造的对象的引用为其他线程所见，也就是this不能在构造函数中逃逸。如下代码：

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

    public FinalExample() {//构造函数
        i=1;       //1.写final域
        obj=this;  //2.this逃逸了
    }

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

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

可以看出this逃逸的危险性。

总结

fianl的语义使得Java程序员能够得到安全保证：只要对象能够正确构造(没有逃逸现象)，那么就不需要使用同步就可以保证任意线程都能够看到final域在构造函数中被初始化之后的值。

x86系统中，final产生的StoreStore和LoadLoad屏障都会被省略掉，因为x86禁止了这类重排序。