Java 面试 -volatile 的内存语义
原子性。对任意 volatile 变量的读/写具有原子性，但类似 volatile++这种复合操作不具有原子性。
[](()2、volatile 写-读建立的 happens-before 关系
对于程序员来说，我们更加需要关注的是 volatile 对线程内存的可见性。
从 JDK1.5（JSR-133）开始，volatile 变量的写-读可以实现线程之间的通信。从内存语义的角度来说，volatile 的写-读与锁的释放-获取有相同的内存效果。
volatile 的写和锁的释放有相同的内存语义
volatile 的读和锁的获取有相同的内存语义
代码示例：
package com.lizba.p1;
/**
<p>
</p>
@Author: Liziba
@Date: 2021/6/9 22:23
*/
public class VolatileExample {
int a = 0;
volatile boolean flag = false;
public void writer() {
a = 1; // 1
flag = true; // 2
}
public void reader() {
if (flag) { // 3
int i = a; // 4
System.out.println(i);
}
}
}
假设线程 A 执行 writer()方法之后，线程 B 执行 reader()方法。根据 happens-before 规则，这个过程建立的 happens-before 关系如下：
根据程序次序规则，1 happens-before 2， 3 happens-before 4。
根据 volatile 规则，2 happens-before 3。
根据 happens-before 的传递性规则，1 happens-before 4。
图示上述 happens-before 关系：
总结：这里 A 线程写一个 volatile 变量后，B 线程读同一个 volatile 变量。A 线程在写 volatile 变量之前所有可见的共享变量，在 B 线程读同一个 volatile 变量后，将立即对 B 线程可见。
?
[](()3、volatile 写-读的内存语义
[](()volatile 写的内存语义
当写一个 volatile 变量时，JMM 会把该线程对应的本地内存中的共享变量值刷新到主内存。
以上面的 VolatileExample 为例，假设 A 线程首先执行 writer()方法，随后线程 B 执行 reader()方法，初始时两个线程的本地内存中的 flag 和 a 都是初始状态。
A 执行 volatile 写后，共享变量状态示意图。
线程 A 在写 flag 变量后，本地内存 A 中被线程 A 更新过的两个共享变量的值被刷新到主内存中，此时 A 的本地内存和主内存中的值是一致的。
[](()volatile 读的内存语义
当读一个 volatile 变量时，JMM 会把该线程对应的本地内存置为无效。线程接下来将会从主内存中读取共享变量。
B 执行 volatile 读后，共享变量的状态示意图。
?
在读 flag 变量后，本地内存 B 包含的值已经被置为无效。此时，线程 B 必须从主内存中重新读取共享变量。线程 B 的读取操作将导致本地内存 B 与主内存中的共享变量的值变为一致。
?
总结 volatile 的写和 volatile 读的内存语义
线程 A 写一个 volatile 变量，实质上是线程 A 向接下来将要读这个 volatile 变量的某个线程发出了（其对共享变量所做修改的）消息。
线程 B 读一个 volatile 变量，实质上是线程 B 接收了之前某个线程发出的（在写这个 volatile 变量之前对共享变量所做修改的）消息。
线程 A 写一个 volatile 变量，随后线程 B 读这个 volatile 变量，这个过程实质上是线程 A 通过主内存向线程 B 发送消息。
?
[](()4、volatile 内存语义实现
程序的重排序分为编译器重排序和处理器重排序（我的前面的博文内容有写哈）。为了实现 volatile 内存语义，JMM 会分别禁止这两种类型的重排序。
?
volatile 重排序规则表
| 是否能重排序 | 第二个操作 | 第二个操作 | 第二个操作 |
| --- | --- | --- | --- |
| 第一个操作 | 普通读/写 | volatile 读 | volatile 写 |
| 普通读/写 | | | NO |
| volatile 读 | NO | NO | NO |
| volatile 写 | | NO | NO |
上图举例：第一行最后一个单元格意思是，在程序中第一个操作为普通读/写时，如果第二个操作为 volatile 写，则编译器不能重排序。
总结上图：
第二个操作是 volatile 写时，都不能重排序。确保 volatile 写之前的操作不会被编译器重排序到 volatile 之后
第一个操作为 volatile 读时，都不能重排序。确保 volatile 读之后的操作不会被编译器重排序到 volatile 之前
第一个操作为 volatile 写，第二个操作为 volatile 读时，不能重排序。
为了实现 volatile 的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
JMM 采取的是保守策略内存屏障插入策略，如下：
在每个 volatile 写操作屏障前面插入一个 StoreStore 屏障。
在每个 volatile 写操作的后面插入一个 StoreLoad 屏障
在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
在每个 volatile 读操作的后面插入一个 LoadStore 屏障。
保守策略可以保证在任意处理器平台上，任意程序中都能得到正确的 volatile 内存语义。
?
保守策略下，volatile 写插入内存屏障后生成的指令序列图：
?
解释：
StoreStore 屏障可以保证在 volatile 写之前，其前面所有普通写操作已经对任意处理器可见了。这是因为 StoreStore 屏障将保障上面所有普通写在 volatile 写之前刷新到主内存。
?
保守策略下，volatile 读插入内存屏障后生成的指令序列图：
解释：
LoadLoad 屏障用来禁止处理器把上面的 volatile 读与下面的普通读重排序。LoadStore 屏障用来禁止处理器把上面的 volatile 读与下面的普通写重排序。
?
上述 volatile 写和 volatile 读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile 写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。
代码示例：
package com.lizba.p1;
/**
<p>
</p>
@Author: Java 开源项目【ali1024.coding.net/public/P7/Java/git】 Liziba
@Date: 2021/6/9 23:48
*/
public class VolatileBarrierExample {
最后
针对以上面试题，小编已经把面试题+答案整理好了
面试专题
除了以上面试题+答案，小编同时还整理了微服务相关的实战文档也可以分享给大家学习
?
还未添加个人签名 2022.04.13 加入
还未添加个人简介
评论