BT

深入理解Java内存模型(六)——final

作者 程晓明 发布于 2013年3月8日 | 被首富的“一个亿”刷屏?不如定个小目标,先把握住QCon上海的优惠吧!

与前面介绍的锁和volatile相比较,对final域的读和写更像是普通的变量访问。对于final域,编译器和处理器要遵守两个重排序规则:

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

下面,我们通过一些示例性的代码来分别说明这两个规则:

public class FinalExample {
    int i;                            //普通变量
    final int j;                      //final变量
    static FinalExample obj;

    public void 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域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含下面2个方面:

  • JMM禁止编译器把final域的写重排序到构造函数之外。
  • 编译器会在final域的写之后,构造函数return之前,插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。

现在让我们分析writer ()方法。writer ()方法只包含一行代码:finalExample = new FinalExample ()。这行代码包含两个步骤:

  1. 构造一个FinalExample类型的对象;
  2. 把这个对象的引用赋值给引用变量obj。

假设线程B读对象引用与读对象的成员域之间没有重排序(马上会说明为什么需要这个假设),下图是一种可能的执行时序:

在上图中,写普通域的操作被编译器重排序到了构造函数之外,读线程B错误的读取了普通变量i初始化之前的值。而写final域的操作,被写final域的重排序规则“限定”在了构造函数之内,读线程B正确的读取了final变量初始化之后的值。

写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经被正确初始化过了,而普通域不具有这个保障。以上图为例,在读线程B“看到”对象引用obj时,很可能obj对象还没有构造完成(对普通域i的写操作被重排序到构造函数外,此时初始值2还没有写入普通域i)。

读final域的重排序规则

读final域的重排序规则如下:

  • 在一个线程中,初次读对象引用与初次读该对象包含的final域,JMM禁止处理器重排序这两个操作(注意,这个规则仅仅针对处理器)。编译器会在读final域操作的前面插入一个LoadLoad屏障。

初次读对象引用与初次读该对象包含的final域,这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系,因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖,大多数处理器也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序(比如alpha处理器),这个规则就是专门用来针对这种处理器。

reader()方法包含三个操作:

  1. 初次读引用变量obj;
  2. 初次读引用变量obj指向对象的普通域j。
  3. 初次读引用变量obj指向对象的final域i。

现在我们假设写线程A没有发生任何重排序,同时程序在不遵守间接依赖的处理器上执行,下面是一种可能的执行时序:

在上图中,读对象的普通域的操作被处理器重排序到读对象引用之前。读普通域时,该域还没有被写线程A写入,这是一个错误的读取操作。而读final域的重排序规则会把读对象final域的操作“限定”在读对象引用之后,此时该final域已经被A线程初始化过了,这是一个正确的读取操作。

读final域的重排序规则可以确保:在读一个对象的final域之前,一定会先读包含这个final域的对象的引用。在这个示例程序中,如果该引用不为null,那么引用对象的final域一定已经被A线程初始化过了。

如果final域是引用类型

上面我们看到的final域是基础数据类型,下面让我们看看如果final域是引用类型,将会有什么效果?

请看下列示例代码:

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域的重排序规则对编译器和处理器增加了如下约束:

  1. 在构造函数内对一个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域在构造函数中被初始化之后的值。

参考文献

  1.  Java Concurrency in Practice

  2.  JSR 133 (Java Memory Model) FAQ

  3.  Java Concurrency in Practice

  4.  The JSR-133 Cookbook for Compiler Writers

Intel® 64 and IA-32 ArchitecturesvSoftware Developer’s Manual Volume 3A: System Programming Guide, Part 1

关于作者

程晓明,Java软件工程师,国家认证的系统分析师、信息项目管理师。专注于并发编程,就职于富士通南大。个人邮箱:asst2003@163.com

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

请教下作者,关于"如果final域是引用类型"这段... by nie runshine

请教下作者,关于"如果final域是引用类型"这段...
这里的final域换为volatile域是否适用?

也就是如果volatile域也为引用类型.
在构造函数内对一个volatile引用的对象的成员域的写入,与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量,这两个操作是否存在happens before关系?

请问 “如果final域是引用类型” 这段 by yan an

请问 “如果final域是引用类型” 这段, 在WriteOne中,已经初始化obj对象了,那么WriteTwo中obj.intArray[0] = 2; 还可能生效么,intArray是final类型,obj.intArray[0] = 1;已经赋过值了
这点不太懂,烦请指教,谢谢

Re: 请问 “如果final域是引用类型” 这段 by nie runshine

可以赋值的,final只是保证field不会被再次赋值,但是field如果是引用类型(同时是可变对象),其内容还是可以更改的。比如final修饰的数组,list,map。
其实你跑一跑就看到效果了 ^_^

Re: 请教下作者,关于 by 程 晓明

谢谢您的关注。

这里的final域换为volatile域是否适用?
--不适用

这两个操作是否存在happens before关系?
--这两个操作之间不一定存在happens before关系。
如果在程序顺序中,对对象成员域的写入,排在对volatile引用的写入的后面,就没有happens before关系。

请教下作者 by yamato kira

之前有文章看过,这里的FinalExample obj应该是非安全发布的吧,如果线程A执行到 obj = new FinalExample ();这里的obj虽然不为null,但有可能当前的构造函数没有执行所有的域都没有被初始化 这时候的final值是什么

不清楚 by zhi li

说得不清楚。图和描述有些地方不一致吧?建议更具体、更深入一些

Re: 请教下作者 by 程 晓明

如果读线程B读到obj不为null,那么读线程B接下来一定可以读到obj所引用的对象的final域(在程序中时变量j),被写线程A写入之后的值。这时候j的值为2.

Re: 不清楚 by 程 晓明

谢谢您的关注。

图和描述确实有点不一致,不好意思。
图片的问题已提交给infoq的发布编辑,后面会做出修正。

请问,您认为那些地方讲的不清楚,那些地方需要更具体和深入。

Re: 不清楚 by 木 登子

文章很好,但是有一点小问题,第一段代码
public void FinalExample () { //构造函数
i = 1; //写普通域
j = 2; //写final域
}
这个构造子有点问题,void应该去掉吧.....

Re: 不清楚 by 程 晓明

void应该去掉,谢谢您的指正。

请问这个是我理解错了,还是您写错了? by zhang bl

先非常感谢作者的共享。写的很透彻,难得的好文章。

原文:
在上图中,写普通域的操作被编译器重排序到了构造函数之外,读线程B错误的读取了普通变量i初始化之前的值。而写final域的操作,被写final域的重排序规则“限定”在了构造函数之内,读线程B正确的读取了final变量初始化之后的值。

写final域的重排序规则可以确保:在对象引用为任意线程可见之前,对象的final域已经被正确初始化过了,而普通域不具有这个保障。以上图为例,在读线程B“看到”对象引用obj时,很可能obj对象还没有构造完成(对普通域i的写操作被重排序到构造函数外,此时初始值2还没有写入普通域i)。

问题:
代码上写的,i一直是i = 1呀,没有i=2呀?最多是i的默认初始值是0。

Re: 请问这个是我理解错了,还是您写错了? by 程 晓明

您的理解是对的,是我写错了。
这里的“2”应该改为“1”:
(对普通域i的写操作被重排序到构造函数外,此时初始值1还没有写入普通域i)

谢谢您的指正。

有三个问题想请教作者 by wang zhichen

有三个问题想请教作者:

1. “在构造函数内对一个final域的写入,与随后把这个被构造对象的引用赋值给一个引用变量,这两个操作之间不能重排序。”
请问,这句话的意思,是final的语义,仅限在构造函数内写一个final变量,才有效么?我如果在实例代码块,或者在声明final成员的地方直接赋初值(比如 final int a = 1;),final的语义规则是否同样有效?


2. “在构造函数内对一个final引用的对象的成员域的写入,与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量,这两个操作之间不能重排序。”
请问如果final引用的对象(假设为a)的成员域,也是一个对象(假设为b),那么对对象b的成员域的写,是否同样符合这一规则?如果对象b的成员域还是一个对象(假设为c),那么对c的成员域的写,是否同样符合这一规则?也就是说,该规则是否可以无尽向下递归?


3. en.wikipedia.org/wiki/Double-checked_locking
该链接是维基百科关于dcl单例模式的一些说明,这个网页中,关于“Usage in Java”这一段的最后说到了,final可以和dcl联合使用。在举的例子中有一句 FinalWrapper<Helper> wrapper = helperWrapper; 并且该文中说,这一句是必不可少的。
请问,这一句为什么必不可少?


谢谢!

final语义能确保线程安全么? by 袁 先虎

我看了你写的Java内存模型中关于final后有个疑问一直没搞清楚,想请教一下:
《Java并发编程实践》中4.4.2章节的“ImprovedList”的例子,不管构造函数传入的list是线程安全的还是不是线程安全的,ImprovedList类总是线程安全的,源码如下,但是我一直不能理解,请帮忙解惑。
下面是我的理解:
1.从你的文章中看final list域只保证构造函数初始化时的安全性,构造完成后,后续的修改JMM是不保证final的安全性的。
2.比如线程A执行了ImprovedList类中同步的修改方法add后,线程B执行非同步的读方法,如contains方法,线程B能看到A的修改么?contains没有同步,可以与add同时进行,也就是list域存在同时读写,有没有正确同步,是不是有数据竞争?
3.我怎么看都觉得这个类不是线程安全的,final修饰引用类型的list到底起了什么作用?请帮忙解惑。

具体源码如下:

@ThreadSafe
public class ImprovedList<T> implements List<T> {
private final List<T> list;

/**
* PRE: list argument is thread-safe.
*/
public ImprovedList(List<T> list) {
this.list = list;
}

public synchronized boolean putIfAbsent(T x) {
boolean contains = list.contains(x);
if (contains)
list.add(x);
return !contains;
}

// Plain vanilla delegation for List methods.
// Mutative methods must be synchronized to ensure atomicity of putIfAbsent.

public int size() {
return list.size();
}

public boolean isEmpty() {
return list.isEmpty();
}

public boolean contains(Object o) {
return list.contains(o);
}

public Iterator<T> iterator() {
return list.iterator();
}

public Object[] toArray() {
return list.toArray();
}

public <T> T[] toArray(T[] a) {
return list.toArray(a);
}

public synchronized boolean add(T e) {
return list.add(e);
}

public synchronized boolean remove(Object o) {
return list.remove(o);
}

public boolean containsAll(Collection<?> c) {
return list.containsAll(c);
}

public synchronized boolean addAll(Collection<? extends T> c) {
return list.addAll(c);
}

public synchronized boolean addAll(int index, Collection<? extends T> c) {
return list.addAll(index, c);
}

public synchronized boolean removeAll(Collection<?> c) {
return list.removeAll(c);
}

public synchronized boolean retainAll(Collection<?> c) {
return list.retainAll(c);
}

public boolean equals(Object o) {
return list.equals(o);
}

public int hashCode() {
return list.hashCode();
}

public T get(int index) {
return list.get(index);
}

public T set(int index, T element) {
return list.set(index, element);
}

public void add(int index, T element) {
list.add(index, element);
}

public T remove(int index) {
return list.remove(index);
}

public int indexOf(Object o) {
return list.indexOf(o);
}

public int lastIndexOf(Object o) {
return list.lastIndexOf(o);
}

public ListIterator<T> listIterator() {
return list.listIterator();
}

public ListIterator<T> listIterator(int index) {
return list.listIterator(index);
}

public List<T> subList(int fromIndex, int toIndex) {
return list.subList(fromIndex, toIndex);
}

public synchronized void clear() {
list.clear();
}
}

Re: final语义能确保线程安全么? by 程 晓明

1:后续的修改JMM是不保证final的安全性的
--是的,后续对final引用的对象的修改不保证线程安全性

2:线程B能看到A的修改么?
--线程B不一定能看的到线程A的修改
是不是有数据竞争?
--是的,可能会产生数据竞争

3:final修饰引用类型的list到底起了什么作用?
--从jdk5开始,final保证初始化安全性。
但不保证后续对final引用的对象的修改的线程安全性。

-------------------------------------------

我估计《Java Concurrency in Practice》的4.4.2是想说明synchronized Adapter技术:
通过adds an additional level of locking且consistent locking 的时候,实现类似Vector的线程安全性。
理由如下:
1:在4-16的示例代码中,有如下注释:
// ... similarly delegate other List methods
2:在4.4.2中,有如下描述:
ImprovedList adds an additional level of locking using its own intrinsic lock.
It does not care whether the underlying List is thread-safe, because it provides its own consistent locking that provides thread safety even if the List is not thread-safe or changes its locking implementation.
注意作者特别强调的“its own consistent locking ”。

从上面两点来看,作者想在4.4.2中说明:
通过增加一个代理层,并在代理层实现一致性的锁定机制,就可以实现线程安全。
但问题是,ImprovedList.java的源代码和4.4.2的讲解不太相符。

《Java Concurrency in Practice》的4.4.2讲的是synchronized Adapter技术。
在《Concurrent Programming in Java, Second Edition》的“2.3.3.1 Adapters”中也提到过这个主题。
其中的类SynchedPoint.java情况和4.4.2的ImprovedList.java情况类似。
在《Concurrent Programming in Java, Second Edition》的“2.3.3.1 Adapters”中,Doug Lea对synchronized Adapter做了如下说明,
As one simple application, synchronized Adapters can be used to place synchronized access and
update methods around a class containing public instance variables, such as a wide-open point
class
Doug Lea在这里指出,access and update methods都需要做同步处理(请注意,SynchedPoint.java的两个get()方法都加了synchronized关键字)。

DCL的 Final 实现相关 by wang zheng

在 “en.wikipedia.org/wiki/Double-checked_locking#ci... 中,对于 DCL提供了一种通过 final 关键字来实现的方式,源码如下:

public class FinalWrapper<T> {
public final T value;
public FinalWrapper(T value) {
this.value = value;
}
}

public class Foo {
private FinalWrapper<Helper> helperWrapper;

public Helper getHelper() {
FinalWrapper<Helper> wrapper = helperWrapper;

if (wrapper == null) {
synchronized(this) {
if (helperWrapper == null) {
helperWrapper = new FinalWrapper<Helper>(new Helper());
}
wrapper = helperWrapper;
}
}
return wrapper.value;
}
}


同时,文章中有如下说明
The local variable wrapper is required for correctness.

请问一下,为什么这个 局部变量 wrapper 是必须的?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

16 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.