被volatile修饰变量的两大特点
- 特点：
- 可见性
- 有序性：加了volatile之后，如果有排序要求，会禁止重排
- 不符合JMM规范的原子性
- 内存语义：
- 当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中
- 当读一个volatile变量时，如果此时收到通知，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量的值
- 所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取
- volatile凭什么可以保证可见性和有序性？
- 凭借内存屏障Memory Barrier来禁止重排
内存屏障（面试重点）
生活case
- 没有管控，顺序难保（屏障起到一种隔离、保护、拦截作用）
- 设定规则，禁止乱序。如上海南京路武警当红灯
- 再说vilatile两大特性：
- 可见：写完后立即刷新回主内存并及时发出通知，大家可以去主内存拿最新值，前面的修改对后面所有线程可见
- 有序性（禁重排）：重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序，若不存在数据依赖关系，可以重排序；存在数据依赖关系，禁止重排序；但重排后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑！
内存屏障是什么
内存屏障（也称内存栅栏，屏障指令等）是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作，避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性（禁重排），但volatile无法保证原子性
- 内存屏障之前的所有写操作都要回写到主内存
- 内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果（实现了可见性）
写屏障(Store Memory Barrier)：告诉处理器在写屏障之前将所有存储在缓存(store buffers)中的数据同步到主内存，也就是说当看到Store屏障指令，就必须把该指令之前的所有写入指令执行完毕才能继续往下执行
读屏障(Load Memory Barrier)：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据
因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。一句话：对一个volatile变量的写，先行发生于任意后续对这个volatile变量的读，也叫写后读。
内存屏障分类
粗分两种
- 读屏障（Load Barrier）：在读指令之前插入读屏障，让工作内存或CPU高速缓存当中的缓存数据失效，重新回到主内存中获取最新数据。
- 写屏障（Store Barrier）：在写指令之后插入写屏障，强制把缓冲区的数据刷回到主内存中。
- 混合屏障实际上只是把读屏障、写屏障混合起来
细分四种
读写两两组合
| 屏障类型 | 指令示例 | 说明 |
|---|---|---|
| LoadLoad | Load1;LoadLoad;Load2 | 保证Load1的读取操作在Load2及后续读取操作之前执行 |
| StoreStore | Store1;StoreStore;Store2 | 在store2及其后的写操作执行前，保证Store1的写操作已经刷新到主内存 |
| LoadStore | Load1;LoadStore;Store2 | 在Store2及其后的写操作执行前，保证Load1的读操作已经结束 |
| StoreLoad | Store1;StoreLoad;Load2 | 保证Store1的写操作已经刷新到主内存后，Load2及其后的读操作才能执行（例如A=5执行完之后，才能执行B=A） |
困难内容
- 什么叫保证有序性？答：通过内存屏障禁重排
- 重排序有可能影响程序的执行和实现，因此，我们有时候希望告诉JVM别自动重排序，我这里不需要重排序，听程序员的。
- 对于编译器的重排序，JMM会根据重排序的规则，禁止特定类型的编译器重排序
- 对于处理器的重排序，Java编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序。
- happens-before之volatile变量规则
- JMM就将内存屏障插入策略分为4种规则
-
读屏障：在每个volatile读操作的后面插入一个LoadLoad屏障和LoadStore屏障（volatile读插入内存屏障后生成的指令序列示意图如下）
-
写屏障：在每个volatile写操作的前面插入StoreStore屏障；在每个volatile写操作的后面插入StoreLoad屏障；
-
volatile特性
保证可见性
保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见
- Code
- 不加volatile，没有可见性，程序无法停止
- 加了volatile，保证可见性，程序可以停止
public class VolatileSeeDemo {
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 -------come in
main 修改完成
t1 -------flag被设置为false，程序停止
【总结】
线程t1中为何看不到被主线程main修改为false的flag的值？
问题可能：
- 主线程修改了flag之后没有将其刷新到主内存，所以t1线程看不到。
- 主线程将flag刷新到了主内存，但是t1一直读取的是自己工作内存中flag的值，没有去主内存中更新获取flag最新的值。
我们的诉求：
- 线程中修改了自己的工作内存中的副本之后，立即将其刷新到主内；
- 工作内存中每次读取共享变量时，都去主内存中重新读取，然后拷贝到工作内存。
解决：
使用volatile修饰共享变量，就可以达到上面的效果，被volatile修饰的变量有以下特点：
- 线程中读取的时候，每次读取都会去主内存中读取共享变量最新的值，然后将其复制到工作内存
- 线程中修改了工作内存中变量的副本，修改之后会立即刷新到主内存
volatile变量的读写过程（了解即可）
Java内存模型中定义的8种每个线程自己的工作内存与主物理内存之间的原子操作
- read：作用于主内存，将变量的值从主内存传输到工作内存
- load：作用于工作内存，将read从主内存传输的变量值放入工作内存变量副本中，即数据加载
- use：作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作
- assign：作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作
- store：作用于工作内存，将赋值完毕的工作变量的值写回给主内存
- write：作用于主内存，将store传输过来的变量值赋值给主内存中的变量
由于上述6条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁，所以，JVM提供了另外两个原子指令：
- lock：作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程。
- unlock：作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用
没有原子性
原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响
volatile变量的符合操作不具有原子性，在高并发的时候，没有办法保证数据一致性和安全性，如多线程i++。还是需要lock、unlock、synchronized
import java.util.concurrent.TimeUnit;
class MyNumber {
volatile int number;
public void addPlusPlus() {
number++;
}
}
public class VolatileNoAtomicDemo {
public static void main(String[] args) {
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(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(myNumber.number);
}
}
import java.util.concurrent.TimeUnit;
class MyNumber {
int number;
public synchronized void addPlusPlus() {
number++;
}
}
public class VolatileNoAtomicDemo {
public static void main(String[] args) {
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(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(myNumber.number);
}
}
使用synchronized，答案正确
读取赋值一个普通变量的情况
- 对于voaltile变量具备可见性，JVM只是保证从主内存加载到线程工作内存的值是最新的，也仅仅是数据加载时是最新的。但是多线程环境下，“数据计算”和“数据赋值”操作可能多次出现，若数据在加载之后，若主内存volatile修饰变量发生修改之后，线程工作内存的操作将会作废去读主内存最新值，操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步，进而导致数据不一致。由此可见volatile解决的是变量读时的可见性问题，但无法保证原子性，对于多线程修改主内存共享变量的场景必须加锁同步。
- 至于怎么去理解这个写丢失的问题，就是再将数据读取到本地内存到写回主内存中有三个步骤：数据加载---->数据计算---->数据赋值，如果第二个线程在第一个线程读取旧值与写回新值期间读取共享变量的值，那么第二个线程将会与第一个线程一起看到同一个值，并执行自己的操作，一旦其中一个线程对volatile修饰的变量先行完成操作刷回主内存后，另一个线程会作废自己的操作，然后重新去读取最新的值再进行操作，这样的话，它自身的那一次操作就丢失了，这就造成了线程安全失败，因此，这个问题需要使用synchronized修饰以保证线程安全性
【同步方法】
【volatile】
如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败，因此对于add方法必须使用synchronized修饰以便保证线程安全
【结论】
volatile变量不适合参与到依赖当前值的运算，如i++，i=i+1之类的，适合用来保存某个状态的boolean值或者int值。也正是由于volatile变量只能保证可见性，在不符合以下规则的运算场景中，我们仍然要通过加锁来保证原子性：
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
- 不依赖当前值：如果你的操作只是简单地读取一个变量的值，并且这个读取操作不会改变变量的值，那么你可以认为结果不依赖于变量的当前值。
- 依赖当前值：如果你的操作需要改变变量的值，比如递增、递减等，那么结果就依赖于变量的当前值，并且在这种情况下需要使用同步机制来保证原子性。
- 变量不需要与其他的状态变量共同参与不变约束（我也不太理解）
面试：为什么volatile不具备原子性
举例i++的例子，在字节码文件中，i++分为三步，间隙期间不同步非原子操作
- 对于volatile变量，JVM只是保证从主内存加载到线程工作内存的值是最新的，也就是数据加载时是最新的，如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，也就造成了线程安全问题。
指令禁重排
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序。若不存在数据依赖关系，可以重排序；若存在数据依赖关系，禁止重排序。重排后的指令绝对不能改变原有的串行语义！
【四种屏障插入情况】
- 在每一个volatile写操作前面插入一个StoreStore屏障：StoreStore屏障可以保证在volatile写之前，其前面所有的普通写操作都已经刷新到主内存中。
- 在每一个volatile写操作后面插入一个StoreLoad屏障：StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序
- 在每一个volatile读操作后面插入一个LoadLoad屏障：LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序
- 在每一个volatile读操作后面插入一个LoadStore屏障：LoadTore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序
- 案例说明（volatile读写前或后加了屏障保证有序性）：
对flag加入volatile可以禁止指令重排
如何正确使用volatile
-
单一赋值可以使用（高效），但是含复合运算赋值不可以使用（i++之类的）
- volatile int a = 10;
- volatile boolean flag = false;
-
状态标志，判断业务是否结束
- 作为一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或任务结束
- 作为一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或任务结束
-
开销较低的读，写锁策略
- 当读远多于写，结合使用内部锁和volatile变量来减少同步的开销
- 原理是：利用volatile保证读操作的可见性（synchronized是重锁，如果读也用这个，性能比较差），利用synchronized保证复合操作的原子性
案例：DCL双端锁
- 问题描述：首先设定一个加锁的单例模式场景
- 在单线程环境下（或者说正常情况下），在“问题代码处”，会执行以下操作，保证能获取到已完成初始化的实例：
- 隐患：在多线程环境下，在“问题代码处”，会执行以下操作，由于重排序导致2，3乱序，后果就是其他线程得到的是null而不是完成初始化的对象，其中第3步中实例化分多步执行（分配内存空间、初始化对象、将对象指向分配的内存空间），某些编译器为了性能原因，会将第二步和第三步重排序，这样某个线程肯能会获得一个未完全初始化的实例：
- 多线程下的解决方案：加volatile修饰
// 通过volatile声明，实现线程安全的延迟初始化。
private volatile static SafeDoubleCheckSingleton singleton;
// 私有化构造方法
private SafeDoubleCheckSingleton(){}
// 双重锁设计
public static SafeDoubleCheckSingleton getInstance(){
if (singleton == null){
// 多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象
synchronized (SafeDoubleCheckSingleton.class){
if (singleton == null){
// 隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程读取
// 解决隐患原理：利用volatile，禁止 "初始化对象"(2) 和 "设置singleton指向内存空间"(3) 的重排序
singleton = new SafeDoubleCheckSingleton();
}
}
}
// 对象创建完毕，执行getInstance()将不需要获取锁，直接返回创建对象
return singleton;
}
总结（面试话术）
volatile可见性
| volatile关键字保证可见性： | 对一个被volatile关键字修饰的变量 |
|---|---|
| 1 | 写操作的话，这个变量的最新值会立即刷新回到主内存中 |
| 2 | 读操作的话，总是能够读取到这个变量的最新值，也就是这个变量最后被修改的值 |
| 3 | 当某个线程收到通知，去读取volatile修饰的变量的值的时候，线程私有工作内存的数据失效，需要重新回到主内存中去读取最新的数据。 |
volatile禁重排
volatile没有原子性
为什么我们Java写了一个volatile关键字，系统底层会加入内存屏障？
内存屏障是什么？
是一种屏障指令，它使得CPU或编译器对屏障指令的前和后所发出的内存操作执行一个排序的约束。也称为内存栅栏或栅栏指令。
内存屏障能干吗？
- 阻止屏障两边的指令重排序
- 写操作时加入屏障，强制将线程私有工作内存的数据刷回主物理内存
- 读操作时加入屏障，线程私有工作内存的数据失效，重新回到主物理内存中获取最新值
内存屏障四大指令
- 在每一个volatile写操作前面插入一个StoreStore屏障
- 在每一个volatile写操作后面插入一个StoreLoad屏障
- 在每一个volatile读操作后面插入一个LoadLoad屏障
- 在每一个volatile读操作后面插入一个LoadStore屏障
一句话总结
volatile写之前的操作，都禁止重排序到volatile之后
public class VolatileExample {
private volatile boolean ready = false;
private int value = 0;
public void writer() {
value = 42; // 非volatile操作
ready = true; // volatile写操作
}
public void reader() {
while (!ready) { /* spin */ }
int x = value; // 使用volatile变量控制的值
}
}
假设writer线程先设置value然后设置ready为true，但如果没有volatile的写操作限制，编译器或处理器可能会将这两行代码重排序，使得ready = true先于value = 42执行。这将导致reader线程可能在value还未被初始化为42之前就读取到了ready的值为true，从而导致reader线程读取到value的旧值，而不是预期的42。
volatile读之后的操作，都禁止重排序到volatile之前
public class VolatileCounter {
private volatile boolean lock = false;
private int count = 0;
public void increment() {
// 尝试获取锁
if (!lock) {
lock = true; // 获取锁
count++; // 增加计数器
lock = false; // 释放锁
}
}
public void readCount() {
while (lock) { /* spin */ } // 等待锁释放
int localCount = count; // 读取计数器的值
// 基于localCount的值做一些事情...
System.out.println("Current count: " + localCount);
}
}
在这个例子中，我们有一个increment方法用于增加共享计数器count的值，并且在修改count之前和之后，会锁定和解锁一个volatile变量lock。这通常称为自旋锁（spin lock）。
现在，假设我们有多个线程尝试调用increment和readCount方法。在readCount方法中，线程首先检查lock是否为false（即锁是否被释放）。如果允许在volatile读操作之后的操作重排序到volatile读操作之前，可能发生以下情况：
- 线程A 正在
increment中，并且已经增加了count的值，但还没有释放lock。 - 线程B 在
readCount中检查lock的值。由于不允许重排序，它将正确地等待lock变为false。 - 然而，如果允许重排序，线程B可能在检查
lock的值之前执行了localCount = count;这一行代码，此时count的值还没有被线程A更新。 - 线程A 最终释放了
lock，线程B现在看到lock为false，但在此之前它已经读取了count的旧值。
因此，线程B可能读取到count的旧值，即使线程A已经完成了对count的更新。这会导致线程B基于不正确的count值进行后续操作，从而破坏了计数器的正确性。通过禁止在volatile读操作之后的操作重排序到volatile读操作之前，我们确保了任何基于volatile变量状态的操作都将按预期的顺序执行，从而避免了这种潜在的数据不一致问题。
volatile写之后volatile读，禁止重排序（禁止volatile读放到volatile写前面）
public class VolatileOrderingExample {
private volatile boolean ready = false;
private volatile int value = 0;
public void writer() {
ready = true;
value = 42;
}
public void reader() {
if (ready && value != 42) {
// 这里期望不会发生，因为value应该已经被设为42
System.out.println("Error: Value not updated to 42.");
}
}
}
在这个例子中，writer线程负责更新value变量，并将ready标志设置为true。reader线程检查ready是否为true，如果是，则检查value是否已经更新为42。volatile关键字用于ready和value，以确保它们在多线程环境中的正确可见性。
问题分析：
- 线程A（
writer线程）设置ready为true，然后更新value为42。 - 线程B（
reader线程）检查ready是否为true，如果是，则检查value。
如果没有volatile写之后volatile读之间的重排序规则，可能发生以下情形：
reader线程能够看到ready的更新，但是由于没有正确的重排序规则，reader线程可能在此时读取value的值。由于writer线程尚未完成更新value的值，reader线程可能读取到value的旧值，而不是预期的42。这将导致reader线程中的条件检查失败，因为value不等于42，从而触发错误信息。
文章说明
该文章是本人学习 尚硅谷 的学习笔记，文章中大部分内容来源于 尚硅谷 的视频尚硅谷JUC并发编程（对标阿里P6-P7），也有部分内容来自于自己的思考，发布文章是想帮助其他学习的人更方便地整理自己的笔记或者直接通过文章学习相关知识，如有侵权请联系删除，最后对 尚硅谷 的优质课程表示感谢。
扫一扫
73
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
