this调用语句必须是构造函数中的第一个可执行语句_Java中final对指令重排的影响...

首先，新年快乐！

---

今天在读《Java并发编程实战》，发现了这么一段程序：

public class Holder {
    private int n;
    public Holder(int n){
        this.n=n;
    }
    public void assertSanity(int n){
        if(n!=this.n){
            throw new AssertionError("");
        }
    }
}

书中说到，new Holder这个操作和assertSanity如果在不同的线程中执行，是有可能抛出异常的。

然后有一行脚注，说如果n是final的，那么就没有问题了。这个我就不能理解了，所以看了下JLS。

然后我们来分析：

无final的情况

假设我们有如下语句：

Holder holder=new Holder(1);

则实际执行的动作如下：

tmpRef=allocate(Holder.class) // 1. 分配空间
invokeConstructor(tmpRef) // 2.执行构造函数
holder=tmpRef // 3. 赋值

正如很多书上提到的，由于指令重排，可能是先执行3，再执行2。这样就导致了开头提到的问题，holder有值了，但是n还没有被构造函数初始化。

有final修饰的情况

但是，为什么书中说有final修饰的情况就没有问题了呢？

还得看JLS 17.5：

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.
对象的构造函数结束，就认为这个对象已经被完全初始化了。 为了保证这个对象的final字段有正确的初始值，只有在这个对象被完全初始化后，这个对象的引用才能被其他线程看到。

然后立马有一个例子：

class FinalFieldExample { 
    final int x;
    int y; 
    static FinalFieldExample f;

    public FinalFieldExample() {
        x = 3; 
        y = 4; 
    } 

    static void writer() {
        f = new FinalFieldExample();
    } 

    static void reader() {
        if (f != null) {
            int i = f.x;  // guaranteed to see 3  
            int j = f.y;  // could see 0
        } 
    } 
}

如果在另外一个线程调用reader方法，那么f.x能保证值是3，而f.y没有final修饰符，则不能保证是4。

所以对于刚刚提到的指令序列：

tmpRef=allocate(Holder.class) // 1. 分配空间
invokeConstructor(tmpRef) // 2.执行构造函数
holder=tmpRef // 3. 赋值

对final字段的赋值，一定会在3（赋值指令）之前完成（并对其他线程可见）。

---

网上也有人提到“对象构造函数内有final域，必须先用构造函数构造对象，再把对象赋给其他引用”。这显然是不对的。

以前一直觉得final关键字很简单，没想到还有这么一个坑呢。