java指令重排_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修饰的情况就没有问题了呢？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关键字很简单，没想到还有这么一个坑呢。