Java面试-final的内存语义

一时失言乱红尘 2021-07-24 22:11 321阅读 0赞

上篇介绍了锁和volatile的内存语义，本文讲述的是final的内存语义，相比之下，final域的读和写更像是普通变量的访问。

### 1、final域的重排序规则final ###

对于final域编译器和处理器遵循两个重排序规则

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

读起来相对拗口，用代码来说明上面两种重排序规则：

package com.lizba.p1;
 
 /** * * * * * @Author: Liziba * @Date: 2021/6/11 20:37 */
 public class FinalExample { 
 
 /** 普通变量 */
 int i;
 /** final变量 */
 final int j;
 /** 对象引用 */
 static FinalExample obj;
 
 /** * 构造函数 */
 public FinalExample() { 
 // 写普通域
 this.i = 1;
 // 写final域
 this.j = 2;
 }
 
 /** * 线程A执行writer写方法 * */
 public static void writer() { 
 obj = new FinalExample();
 }
 
 /** * 线程B执行reader读方法 * */
 public static void reader() { 
 // 读对象的引用
 FinalExample finalExample = obj;
 // 读普通域
 int a = finalExample.i;
 // 读final域
 int b = finalExample.j;
 }
 }

假设线程A执行writer()方法，线程B执行reader()方法。下面来通过这两个线程的交互来说明这两个规则。

### 2、写final域的重排序规则 ###

写final域的重排序禁止吧final域的写重排序到构造函数之外。通过如下方式来实现：

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

现在开始分析writer()方法：

/** * 线程A执行writer写方法 * */
    public static void writer() { 
        obj = new FinalExample();
    }

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

首先假设线程B读对象引用与读对象的成员域之间没有重排序，则下图是其一种执行可能  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center]

**线程执行时序图**

### 3、读final与的重排序规则 ###

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

解释：初次读对象引用与初次读该对象包含的final域，这两个操作之间存在间接依赖关系。

*  编译器遵守间接依赖关系，编译器不会重排序这两个操作
 *  **大多数处理器**也遵守间接依赖，不会重排序这两个操作。但是**少部分处理器允许对存在间接依赖关系的操作做重排序（比如alpha处理器），这个规则就是专门针对这种处理器的**。

**分析reader()方法：**

/** * 线程B执行reader读方法 * */
    public static void reader() { 
        // 读对象的引用
        FinalExample finalExample = obj;
        // 读普通域
        int a = finalExample.i;
        // 读final域
        int b = finalExample.j;
    }

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

假设B线程所处的处理器不遵守间接依赖关系，且A线程执行过程中没有发生任何重排序，此时存在如下的执行时序：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 1]

**线程执行时序图**

\*\*上图B线程中读对象的普通域被重排序到处理器读取对象引用之前，\*\*此时普通域i还没有被线程A写入，因此这是一个错误的读取操作。但是final域的读取会被重排序规则把读final域的操作“限定”在读该final域所属对象的引用读取之后，此时final域已经被正确的初始化了，这是一个正确的读取操作。  
  
**总结：**  
读final域的重排序规则可以确保，在读一个对象的final域之前，一定会先读包含这个final域的对象的引用。

### 4、final域为引用类型 ###

上面讲述了基础数据类型，如果final域修饰的引用类型又该如何？

package com.lizba.p1;
 
 /** * * final 修饰引用类型变量 * * * @Author: Liziba * @Date: 2021/6/11 21:52 */
 public class FinalReferenceExample { 
 
 /** final是引用类型 */
 final int[] intArray;
 static FinalReferenceExample obj;
 
 /** * 构造函数 */
 public FinalReferenceExample() { 
 this.intArray = new int[1]; // 1
 intArray[0] = 1; // 2
 }
 
 /** * 写线程A执行 */
 public static void writer1() { 
 obj = new FinalReferenceExample(); // 3
 }
 
 /** * 写线程B执行 */
 public static void writer2() { 
 obj.intArray[0] = 2; // 4
 }
 
 /** * 读线程C执行 */
 public static void reader() { 
 if (obj != null) { // 5
 int temp = obj.intArray[0]; // 6
 }
 }
 }

如上final域为一个int类型的数组的引用变量。对应引用类型，写final域的重排序对编译器和处理器增加了如下约束：

1.  在构造函数内对一个final引用的对象的成员域的写入，与随后在构造函数外把这个被构造对象的引用赋值给另一个引用变量，这两个操作不能重排序。

对于上述程序，假设A执行writer1()方法，执行完后线程B执行writer2()方法，执行完后线程C执行reader()方法。则存在如下线程执行时序：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 2]

**引用型final的执行时序图**

JMM对于上述代码，可以确保读线程C至少能看到**写线程A在构造函数中对final引用对象的成员域的写入**。即写线程C至少能看到数组下标0的值为1。但是写线程B对数组元素的写入，读线程C可能看得到可能看不到。JMM不能保证线程B的写入对读线程C可见。因为写线程B和读线程C之间存在数据竞争，此时的执行结果不可预知。  
此时如果想确保读线程C看到写线程B对数组元素的写入，可以结合同步原语（volatile或者lock）来实现。

### 5、为什么final引用不能从构造函数内“逸出” ###

本文一直在说写final域的重排序规则可以确保：在引用变量为任意线程可见之前，该引用变量指向的对象的final域已经在构造函数中被正确初始化了。那究竟是如何实现的呢？  
其实这需要另一个条件：在构造函数内部，不能让这个被构造对象的引用被其它线程所见。也就是对象引用不能在构造函数中“逸出”。  
****

**示例代码：**

package com.lizba.p1;
 
 /** * * final引用逸出demo * * * @Author: Liziba * @Date: 2021/6/11 22:33 */
 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可见了。**因为1和2允许重排序，所以线程B可能无法看到final域被正确初始化后的值。实际执行的时序图可能如下所示：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 3]

**多线程执行时序图**  
**总结：**  
在构造函数返回之前，被构造对象的引用不能为其他线程可见，因为此时的final域可能还没被初始化。而在构造函数返回后，任意线程都将保证能看到final域正确初始化之后的值。  
****

### 6、final语义在处理器中的实现 ###

举例X86处理器中final语义的具体实现。  
在编译器中会存在如下的处理：

1.  写final域的重排序规则会要求编译器在final域的写之后，构造函数return之前插入一个StoreStore屏障
2.  读final域的重排序规则要求编译器在读final域的操作前插入一个LoadLoad屏障

但是，由于X86处理器不会对写-写操作做重排序，所以在X86处理器中，写final域需要的StoreStore屏障会被省略。同样，由于X86处理器不会对存在间接依赖关系的操作做重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。因此，在X86处理器中，final域的读/写不会插入任何内存屏障。

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

在旧的Java内存模型中，一个最严重的缺陷就是现场可能看到final域的值会改变。比如一个线程读取一个被final域的值为0（未初始化之前的默认值），过一段时间再读取初始化后的final域的值，却发现变为了1。因此为了修复此漏洞，JSR-133增强了final语义。  
总结：  
通过为final增加写和读重排序规则，可以为Java程序员提供初始化安全保障：只要对象正确构造（被构造对象额引用在构造函数中没有“逸出”），那么不需要使用同步原语（volatile和lock的使用）就可以保障任意线程都能看到这个final域在构造函数中被初始化之后的值。

文章总结至《Java并发编程艺术》，下篇总结“happens-before”，敬请关注。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center]: /images/20210724/810eecf76d9147278a4699939f46eee5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210724/6c403c702a354fd799c839ac6f740364.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210724/87ed01186d4541769f7941b387e50c04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTI1MjE5_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20210724/4b4f6d79e1464c4897e1caa612295ef4.png