首先,新年快乐!
今天在读《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'sfinal
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关键字很简单,没想到还有这么一个坑呢。