- 原子性。对任意volatile变量的读/写具有原子性,但类似volatile++这种复合操作不具有原子性。
[](()2、volatile写-读建立的happens-before关系
对于程序员来说,我们更加需要关注的是volatile对线程内存的可见性。
从JDK1.5(JSR-133)开始,volatile变量的写-读可以实现线程之间的通信。从内存语义的角度来说,volatile的写-读与锁的释放-获取有相同的内存效果。
-
volatile的写和锁的释放有相同的内存语义
-
volatile的读和锁的获取有相同的内存语义
代码示例:
package com.lizba.p1;
/**
-
-
@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;
/**
-
-
volatile屏障示例
-
@Author: Java开源项目【ali1024.coding.net/public/P7/Java/git】 Liziba
-
@Date: 2021/6/9 23:48
*/
public class VolatileBarrierExample {
最后
针对以上面试题,小编已经把面试题+答案整理好了
面试专题
除了以上面试题+答案,小编同时还整理了微服务相关的实战文档也可以分享给大家学习
[外链图片转存中…(img-MUwoLCTV-1650436024358)]
[外链图片转存中…(img-7JmsZLwa-1650436024358)]
面试专题
[外链图片转存中…(img-uFSZ0EMn-1650436024359)]
除了以上面试题+答案,小编同时还整理了微服务相关的实战文档也可以分享给大家学习
[外链图片转存中…(img-T6GKRYwC-1650436024360)]
[外链图片转存中…(img-bjblzqk8-1650436024360)]
[外链图片转存中…(img-0SZb4XVd-1650436024361)]