java内存模型 final域的内存语义,happens-before

本文深入探讨了Java内存模型(JMM)中final域的内存语义,包括写final域和读final域的重排序规则,确保对象在引用可见前已正确初始化。此外,文章还解释了为何final引用不能从构造函数内溢出,以及final语义在处理器中的实现。同时,介绍了happens-before原则,包括其定义、设计意图和规则,为理解多线程程序的内存可见性提供了关键指导。
摘要由CSDN通过智能技术生成

目录

final域的内存语义

final域的重排序规则

写final域的重排序规则

读final域的重排序规则

final域为引用类型

为什么final引用不能从构造函数内溢出

final语义在处理器中的实现

JSR-133为什么要增强final的语义

happens-before

JMM的设计

happens-before的定义

 happens-before规则


final域的内存语义

final域的重排序规则

对于final域,编译器和处理器要遵守两个重排序规则。

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

2)初次读一个包含final域的对象的引用,与随后初次读这个final域,这两个操作之间不能 重排序。

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

这里假设一个线程A执行writer()方法,随后另一个线程B执行reader()方法。下面我们通过 这两个线程的交互来说明这两个规则。

写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含 下面2个方面。

1)JMM禁止编译器把final域的写重排序到构造函数之外。

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

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

1)构造一个FinalExample类型的对象。

2)把这个对象的引用赋值给引用变量obj。

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

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

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

读final域的重排序规则

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

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

reader()方法包含3个操作。

  • 初次读引用变量obj。
  • 初次读引用变量obj指向对象的普通域j。
  • 初次读引用变量obj指向对象的final域i。

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

在图中,读对象的普通域的操作被处理器重排序到读对象引用之前。读普通域时,该 域还没有被写线程A写入

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值