Final相关的内存语义
final相关的两个重排序规则
- 在构造函数中对一个final域的引入，与随后把这个被构造对象的引用赋值给另一个引用变量，这两个操作之间不能重排序。（好拗口，其实说白了就是，final修饰的变量，在构造函数初始化完成时，一定是已经初始化了的）—写规则
- 初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。（也挺拗口😓） — 读规则
还是通过代码来说明这两个规则：
public class FinalExample{
int i; // 普通变量 --- A
final int j; // final变量 ---B
static FinalExample obj; // 当前类的实例 ---C
public void FinalExample{ // 构造函数
i = 1; // 写普通域 --——D
j = 2; // 写final域 ---E
} ---F
public static void writer(){ // 由写线程A执行
obj = new FinalExample(); --G
} ---H
public static void reader(){ // 由读线程B执行
FinalExample object = obj; // 读对象引用 --I
int a = object.i; // 读普通域 ---J
int b = object.j; // 读final域 ---K
} ---L
}
假设线程X执行写方法writer()，线程Y执行读方法reader()。
写final域的重排序规则
禁止把final域的写 重排序 到构造函数之外。实际上有以下两层意思：
- JMM禁止编译器把final域的写 重排序 到构造函数之外。 — 编译器重排序层面
- 编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。StoreStore禁止处理器把final域的写操作 重排序 到构造函数之外。 — 处理器重排序层面。 也就是说，上文代码中E语句之后，F语句之前会添加一个StoreStore指令。
来分析下write()方法，也就是G语句，这条语句包含了两个动作：
- 构造一个对象
- 将这个对象的引用 赋值给 引用变量obj
而如果线程X和线程Y现在执行，可能会有这么一个执行顺序(普通域的写 被编译器重排序到构造函数之外)
| 执行顺序 | 线程X-执行writer | 线程Y-执行reader |
|---|---|---|
| 1 | 构造函数开始执行 | |
| 2 | 写final域 j=2 | |
| 3 | StoreStore屏障 | |
| 4 | 构造函数执行结束 | |
| 5 | 将构造对象的引用，赋值给obj | |
| 6 | 读对象应用 obj | |
| 7 | 对对象的普通域，i = 未初始化数据，默认值0 | |
| 8 | 读对象的final域，j=2（线程X写入的数据） | |
| 9 | 写普通域 i =1 | |
写final域的重排序规则可以确保：在对象引用obj为任意线程可见之前，对象的final域赋值已经被执行过了。而普通域则不具有这个保障。
读final域的重排序规则
在一个线程中，初次读 对象引用obj 与初次读 此对象包含的final域，JMM禁止处理器重排序这两个操作（注意，这个规则仅针对处理器）。
而编译器则会在 读final域 操作 的前面插入一个LoadLoad屏障。
初次读 对象引用obj，与初次读 该对象包含的final域，两个操作之间存在间接依赖关系，所以编译器不会重排序这两个操作。
reader方法包含三个操作：
- 初次读 引用变量obj，语句I
- 初次读 引用变量obj的普通域，语句J
- 初次读 引用变量obj的final域，语句K
如果线程X和线程Y现在执行，可能会有这样的执行顺序
| 执行顺序 | 线程X-执行writer | 线程Y-执行reader |
|---|---|---|
| 1 | 构造函数开始执行 | 读对象的普通域 |
| 2 | 写普通域 i = 1 | |
| 3 | 写final域 | |
| 4 | StoreStore屏障 | |
| 5 | 构造函数执行结束 | |
| 6 | 读引用对象 obj | |
| 7 | LoadLoad屏障 | |
| 8 | 读对象的final域 j | |
在这里，读对象的普通域操作，被处理器重排序到读对象引用obj之前，而这时候obj还没有初始化，普通域i的值也还没被线程X初始化。所以这个操作是错误的，拿不到对应数据。
而读对象的final域，由于加入了LoadLoad屏障，不会被重排序在构造函数之外执行，所以能确保读到正确的数据。
总结--对于基本类型
对于基本类型的final域，
- 针对写操作，会在final域写之后，return;之前插入StoreStore屏障，避免final域的写被重排序到构造函数之外。
- 针对读操作，会在final域读之前，插入LoadLoad屏障，避免final域的读被重排序在构造函数之外（主要是避免被重排在构造函数之前，这样还未初始化就被读了，脏读）
Final如果修饰的是引用类型
JMM对引用类型的写final域操作增加了一个重排序规则：
在构造函数内部对一个fina引用的对象的成员域写入，与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
示例代码：
public class FinalReferenceExample{
final int[] intArrays; // final修饰引用类型
static FinalReferenceExample obj;
public FinalReferenceExample(){
intArrays = new int[1]; // 1
intArrays[0] = 1; // 2
}
public static void writeOne(){ // 写线程A执行
obj = new FinalReferenceExmaple(); // 3
}
public static void writeTwo(){ // 写线程B执行
obj.intArrays[0] = 2; // 4
}
public static void reader(){ // 读线程C执行
if(obj != null){ // 5
int temp1 = obj.intArrays[0]; // 6
}
}
}
假设A先执行，结束后B和C执行，那么可能执行的顺序如下：
| 执行顺序 | 线程A-执行writeOne | 线程B-执行writeTwo | 线程C-执行reader |
|---|---|---|---|
| 1 | 构造函数开始执行-语句3 | ||
| 2 | 语句1-写final域 | ||
| 3 | 语句2-对final域引用的对象的成员域写入 | ||
| 4 | StoreStore屏障，在构造函数return之前插入 | ||
| 5 | 把构造对象的引用，赋值给obj—语句3 | ||
| 6 | 语句5-执行，读 对象引用 | ||
| 7 | LoadLoad屏障 | ||
| 8 | 语句6-读final域引用的成员域 | ||
| 9 | 语句4-写final域引用的成员域 | ||
说明：
- 由于writeOne是调用构造器，构造对象引用，而final域引用的初始化是在构造器中，所以线程A执行的结果，对B、C线程都可见
- 语句1和3 不会重排序（final的JMM重排序规则），语句2和3也不会重排序（类似原因，final）。
- 语句1和2 存在数据依赖，所以不会重排序
- 线程B和线程C之间的结果不可预知，二者存在数据竞争，所以可能C取到的obj.intArrays[0]是1，可能是2。如果需要保证C看到的是B的写入，那么要用volatile或者lock/synchronized来实现同步。
- 在构造函数返回前，被构造对象的引用 不能为其他线程可见，因为此时的final域可能还没被初始化。在构造函数返回后，由于storesotre屏障，会将final数据刷新到主内存中，任意线程都将保证能看到final域被正确初始化之后的值。
对于引用类型，final修饰后其实基本原理一样，写操作 都是要在return之前插入storestore屏障，读操作 都是要在其之前插入LoadLoad操作，都是针对构造函数范围与final域的操作来禁止重排。
但是对于X86处理器，首先不会对写-写操作做重排序，所以StoreStore会被省略；其次不会对存在间接依赖关系的操作做重排序，所以LoadLoad也会被省略，所以在X86处理器中，final域的读写不会插入任何内存屏障。
总结
- 顺序一致性内存模型，是一个理论的参考模型，JMM和内存处理器模型在设计时通常会参照顺序一致性内存模型，同时做一些放松，以提高执行性能。
- 所有处理器，对Store-Load重排序都是允许的，因为写、读操作都使用了写缓冲区，写缓冲区可能导致写-读重排序。同样，可以看到这些处理器内存模型都是允许更早读到当前处理器的写，同样是因为写缓冲区：由于写缓冲区仅对当前处理器可见，这个特性导致当前处理器可以比其他处理器先看到临时保存在自己的写缓冲区中的写。
JMM的内存可见性保证
Java程序的内存可见性保证按程序类型可以分为下列三类：
- 单线程程序。单线程程序不会出现内存可见性问题。编译器，runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
- 正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
- 未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，null，false）。
