保证可见性
保证不同线程对某个变量完成操作后结果及时可见,即该共享变量一旦改变所有线程立即可见代码示例
- 不加 volatile,没有可见性,程序无法停止
- 加了 volatile,保证可见性,程序可以停止
volatile 变量读写过程
public class VolatileSeeDemo {
/**
* t1 -------come in
* main 修改完成
* t1 -------flag被设置为false,程序停止
*/
static volatile boolean flag = true;
public static void main(String[] args) {
new Thread(() -> {
System.out.println(Thread.currentThread().getName() + "\t-------come in");
while (flag) {
}
System.out.println(Thread.currentThread().getName() + "\t-------flag被设置为false,程序停止");
}, "t1").start();
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
//更新flag值
flag = false;
System.out.println(Thread.currentThread().getName() + "\t 修改完成");
}
}
线程 t1 中为何看不到被主线程 main 修改为 false 的 flag 的值?
-
问题可能:
- 主线程修改了flag之后没有将其刷新到主内存,所以t1线程看不到。
- 主线程将flag刷新到了主内存,但是t1一直读取的是自己工作内存中flag的值,没有去主内存中更新获取flag最新的值。
-
我们的诉求
- 线程中修改了工作内存中的副本之后,立即将其刷新到主内存;
- 工作内存中每次读取共享变量时,都去主内存中重新读取,然后拷贝到工作内存。
-
解决
使用volatile修饰共享变量,就可以达到上面的效果,被volatile修改的变量有以下特点:
- 线程中读取的时候,每次读取都会去主内存中读取共享变量最新的值,然后将其复制到工作内存
- 线程中修改了工作内存中变量的副本,修改之后会立即刷新到主内存
volatile 变量的读写过程
Java内存模型中定义的8种工作内存与主内存之间的原子操作
read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→ lock(锁定)→unlock(解锁)- read: 作用于主内存,将变量的值从主内存传输到工作内存,主内存到工作内存
- load: 作用于工作内存,将read从主内存传输的变量值放入工作内存变量副本中,即数据加载
- use: 作用于工作内存,将工作内存变量副本的值传递给执行引擎,每当JVM遇到需要该变量的字节码指令时会执行该操作
- assign: 作用于工作内存,将从执行引擎接收到的值赋值给工作内存变量,每当JVM遇到一个给变量赋值字节码指令时会执行该操作
- store: 作用于工作内存,将赋值完毕的工作变量的值写回给主内存
- write: 作用于主内存,将store传输过来的变量值赋值给主内存中的变量
-
lock: 作用于主内存,将一个变量标记为一个线程独占的状态,只是写时候加锁,就只是锁了写变量的过程。
-
unlock: 作用于主内存,把一个处于锁定状态的变量释放,然后才能被其他线程占用
没有原子性
volatile 变量的复合操作(如 i++)不具有原子性示例代码
class MyNumber {
volatile int number = 0;
public void addPlusPlus() {
number++;
}
}
public class VolatileNoAtomicDemo {
public static void main(String[] args) throws InterruptedException {
MyNumber myNumber = new MyNumber();
for (int i = 1; i <= 10; i++) {
new Thread(() -> {
for (int j = 1; j <= 1000; j++) {
myNumber.addPlusPlus();
}
}, String.valueOf(i)).start();
}
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println(Thread.currentThread().getName() + "\t" + myNumber.number);
}
}
读取赋值一个普通变量的情况
当线程 1 对主内存对象发起 read 操作到 write 操作第一套流程的时间里,线程 2 随时都有可能对这个主内存对象发起第二套操作
不保证原子性
对于 volatile 变量,JVM 只是保证从主内存加载到线程工作内存的值是最新的,也就是数据加载时是最新的。
多线程环境下,"数据计算"和"数据赋值"操作可能多次出现,即操作非原子。若数据在加载之后,若主内存 count 变量发生修改之后,由于线程工作内存中的值在此前已经加载,从而不会对变更操作做出相应变化,即私有内存和公共内存中变量不同步,进而导致数据不一致。
由此可见 volatile 解决的是变量读时的可见性问题,但无法保证原子性,对于多线程修改共享变量的场景必须使用加锁同步从 i++ 的字节码角度说明
public class Test01 {
public volatile int n;
public void add() {
n++; //不具备原子性,该操作是先读取值,然后写回一个新值,相当于原来的值加上1,分3步完成
}
}
我们对 Test01.class
进行反编译
leam@Leam-MacBook-Pro locks % javap -c Test01.class
Compiled from "Test01.java"
public class dev.matrixlab.juc.locks.Test01 {
public volatile int n;
public dev.matrixlab.juc.locks.Test01();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public void add();
Code:
0: aload_0
1: dup
2: getfield #2 // Field n:I
5: iconst_1
6: iadd
7: putfield #2 // Field n:I
10: return
}
我们可以看到上述高亮部分 n++
被拆分成了 3 个指令
- 执行 getfield 拿到原始 n;
- 执行 iadd 进行加 1 操作;
- 执行 putfield 写把累加后的值写回。
原子性指的是一个操作是不可中断的,即使是在多线程环境下,一个操作一旦开始就不会被其他线程影响。
如果第二个线程在第一个线程读取旧值和写回新值期间读取 i 的域值,那么第二个线程就会与第一个线程一起看到同一个值,并执行相同值的加 1 操作,这也就造成了线程安全失败,因此对于 add 方法必须使用 synchronized 修饰,以便保证线程安全。
既然保证了可见性,为什么不能保证原子性?
volatile 主要是对其中部分指令做了处理。
要use(使用)一个变量的时候必需load(载入),要载入的时候必需从主内存read(读取)这样就解决了读的可见性。
写操作是把assign和store做了关联(在assign(赋值)后必需store(存储))。store(存储)后write(写入)。也就是做到了给一个变量赋值的时候一串关联指令直接把变量值写到主内存。 就这样通过用的时候直接从主内存取,在赋值到直接写回主内存做到了内存可见性。
总结
Volatile 变量不适合参与到依赖当前值的运算
read-load-use 和 assign-store-write 成为了两个不可分割的原子操作,但是在 use 和 assign 之间依然有极小的一段真空期,有可能变量会被其他线程读取,导致写丢失一次。
但是无论在哪一个时间点主内存的变量和任一工作内存的变量的值都是相等的。这个特性就导致了volatile变量不适合参与到依赖当前值的运算,如i = i + 1; i++;之类的那么依靠可见性的特点volatile可以用在哪些地方呢? 通常volatile用做保存某个状态的boolean值or int值。
《深入理解Java虚拟机》提到:由于 volatile 变量只能保证可见性,在不符合以下两条规则的运算场景中,我们仍然要通过加锁(使用 synchronized、java.util.concurrent 中的锁或原子类)来保证原子性:
- 运算结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
面试回答
JVM 的字节码,i++ 分成三步,间隙期不同步非原子操作(i++)
对于 volatile 变量,JVM 只是保证从主内存加载到线程工作内存的值是最新的,也只是数据加载时时最新的。如果第二个线程在第一个线程读取旧值和写回新值期间读取 i 的域值,也就造成了线程安全问题。
指令禁重排
说明与案例
重排序
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段,有时候会改变程序语句的先后顺序。不存在数据依赖关系,可以重排序;存在数据依赖关系,禁止重排序。但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
重排序的分类和执行流程
- 编译器优化的重排序: 编译器在不改变单线程串行语义的前提下,可以重新调整指令的执行顺序
- 指令级并行的重排序: 处理器使用指令级并行技术来讲多条指令重叠执行,若不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序
- 内存系统的重排序: 由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是乱序执行
数据依赖性
若两个操作访问同一变量,且这两个操作中有一个为写操作,此时两操作间就存在数据依赖性。
案例
不存在数据依赖关系,可以重排序===> 重排序OK 。
重排前 | 重排后 |
---|---|
int a = 1; //1 int b = 20; //2 int c = a + b; //3 | int b = 20; //1 int a = 1; //2 int c = a + b; //3 |
结论:编译器调整了语句的顺序,但是不影响程序的最终结果。 | 重排序OK |
存在数据依赖关系,禁止重排序===> 重排序发生,会导致程序运行结果不同。
编译器和处理器在重排序时,会遵守数据依赖性,不会改变存在依赖关系的两个操作的执行,但不同处理器和不同线程之间的数据性不会被编译器和处理器考虑,其只会作用于单处理器和单线程环境,下面三种情况,只要重排序两个操作的执行顺序,程序的执行结果就会被改变。
名称 | 代码示例 | 说明 |
---|---|---|
写后读 | a = 1; b = a; | 写一个变量之后,再读这个位置 |
写后写 | a = 1; a = 2; | 写一个变量之后,在写这个变量 |
读后写 | a = b; b = 1; | 读一个变量之后,再写这个变量 |
volatile 的底层实现是通过内存屏障
-
volatile 有关的精致指令重排的行为
第一个操作 第二个操作:普通读写 第二个操作:volatile读 第二个操作:volatile写 普通读写 可以重排 可以重排 不可以重排 volatile读 不可以重排 不可以重排 不可以重排 volatile写 可以重排 不可以重排 不可以重排 - 当第一个操作为volatile读时,不论第二个操作是什么,都不能重排序,这个操作保证了volatile读之后的操作不会被重排到volatile读之前。
- 当第一个操作为volatile写时,第二个操作为volatile读时,不能重排
- 当第二个操作为volatile写时,不论第一个操作是什么,都不能重排序,这个操作保证了volatile写之前的操作不会被重排到volatile写之后
-
四大屏障的插入情况
-
在每一个volatile写操作前面插入一个StoreStore屏障--->StoreStore屏障可以保证在volatile写之前,其前面所有的普通写操作都已经刷新到主内存中。
-
在每一个volatile写操作后面插入一个StoreLoad屏障--->StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序
-
在每一个volatile读操作后面插入一个LoadLoad屏障--->LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序
-
在每一个volatile读操作后面插入一个LoadStore屏障--->LoadTore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序
-
代码示例
// 什么顺序读?什么顺序写?
public class VolatileTest {
int i = 0;
volatile boolean flag = false;
public void write() {
i = 2;
flag = true;
}
public void read() {
if (flag) {
System.out.println(i);
}
}
}
volatile 写指令
- 在每一个 volatile 写操作之前插入一个 StoreStore 屏障
- 在每一个 volatile 写操作后面插入一个 StoreLoad 屏障
volatile 写之前的操作都禁止重排序到 volatile 之后
volatile 读指令
- 在每一个 volatile 读操作后面插入一个 LoadLoad 屏障
- 在每一个 volatile 读操作后面插入一个 LoadStore 屏障
volatile 读之后的操作,都禁止重排序到 volatile 之前