JUC并发编程第六章——volatile与JMM

标签：JUC volatile 屏障 线程 内存 JMM 操作 排序

1 被volatile修饰的变量有两大特点

• 特点：

• • 可见性
  • 有序性：有排序要求，有时需要禁重排

• 内存语义：

• • 当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中
  • 当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量的值
  • 所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取

一句话，volatile修饰的变量在某个工作内存修改后立刻会刷新会主内存，并把其他工作内存的该变量设置为无效。

• volatile凭什么可以保证可见性和有序性？

• • 内存屏障Memory Barrier

---

2 内存屏障（面试重点必须拿下）

2.1 生活case

• 没有管控，顺序难保 ----> 例如：节假日旅游景点在没有管控情况下人挤人
• 设定规则，禁止乱序 ----> 例如：上海南京路武警“人墙”当红灯
• 再说volatile两大特性：

• • 可见：写完后立即刷新回主内存并及时发出通知，大家可以去主内存拿最新版，前面的修改对后面所有线程可见
  • 有序性（禁重排）：

• • • 重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序，若不存在数据依赖关系，可以重排序；存在数据依赖关系，禁止重排序；但重排后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑！

---

2.2 是什么

内存屏障（也称内存栅栏，屏障指令等）是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作，避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性（禁重排），但volatile无法保证原子性

• 内存屏障之前的所有写操作都要回写到主内存
• 内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果（实现了可见性）

写屏障(Store Memory Barrier)：告诉处理器在写屏障之前将所有存储在缓存(store buffers)中的数据同步到主内存，也就是说当看到Store屏障指令，就必须把该指令之前的所有写入指令执行完毕才能继续往下执行 读屏障(Load Memory Barrier)：处理器在读屏障之后的读操作，都在读屏障之后执行 (因为前面的写屏障已经保证全部写完了，主内存中都是最新数据了)。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。

因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。

一句话：对一个volatile变量的写，先行发生于任意后续对这个volatile变量的读，也叫写后读。

---

2.3 内存屏障分类

粗分两种：

• 读屏障（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及其后的读操作才能执行

2.4 困难内容

• 什么叫保证有序性？----->通过内存屏障禁重排

• • 重排序有可能影响程序的执行和实现，因此，我们有时候希望告诉JVM别自动重排序，我这里不需要重排序，一切听我的。
  • 对于编译器的重排序，JMM会根据重排序的规则，禁止特定类型的编译器重排序
  • 对于处理器的重排序，Java编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序。

• happens-before之volatile变量规则

第一个操作	第二个操作：普通读写	第二个操作：volatile读	第二个操作：volatile写
普通读写	可以重排	可以重排	不可以重排
volatile读	不可以重排	不可以重排	不可以重排
volatile写	可以重排	不可以重排	不可以重排

当第一个操作为volatile读时，不论第二个操作是什么，都不能重排序，这个操作保证了volatile读之后的操作不会被重排到volatile读之前。

当第一个操作为volatile写时，第二个操作为volatile读时，不能重排

当第二个操作为volatile写时，不论第一个操作是什么，都不能重排序，这个操作保证了volatile写之前的操作不会被重排到volatile写之后

ps：volatile读/写代表读取/写入一个volatile修饰的变量，普通读写代表在volatile读/写前后对非volatile修饰的变量的读取/写入操作

• JMM就将内存屏障插入策略分为4种规则

• • 读屏障：在每个volatile读操作的后面插入一个LoadLoad屏障或者LoadStore屏障

• 
• 加了这两个屏障(一个禁止后面的读和当前读重排，一个禁止后面的写和当前写重排)就可以保证这个volatile读不可能和后续的读或写重排序。
• • 写屏障：在每个volatile写操作的前面插入StoreStore屏障；在每个volatile写操作的后面插入StoreLoad屏障；

    

两个屏障，一个加在volatile写之前的StoreStore屏障，防止上面的写操作和当前volatile写重排；一个加在volatile写之后的StoreLoad屏障，防止后面的读操作和当前volatile重排。(如果后面是volatile写，由于后一个volatile写会在它之前，也就是两个volatile写之间加一个StoreStore，所以不用担心两个volatile写会重排)

我的疑问：

volatile写操作之前不是会加一个StoreStore屏障吗？这不是只能保证所有写操作不能和当前volatile写重排，它怎么能保证普通读和当前volatile写不进行重排？

gpt的回答：

确实，volatile写操作之前会插入一个StoreStore屏障，这个屏障确保了在volatile写操作之前的所有普通写操作都已经完成，并且对其他处理器可见。然而，这个屏障并不直接阻止普通的读操作与volatile写操作之间的重排序。

在Java内存模型（JMM）中，volatile写操作本身就有一个很强的内存屏障效应，它确保了对volatile变量的写入操作之前的所有读和写操作都不会被重排序到volatile写之后。这意味着，即使没有明确的StoreStore屏障，volatile写的内存屏障效应也足够保证普通读操作不会与volatile写操作发生重排序。

总结一下，volatile写操作保证了以下几点：

1. 在volatile写操作之前的所有普通写操作都会在volatile写之前完成，并且对其他处理器可见。
2. 在volatile写操作之前的所有普通读操作都不会被重排序到volatile写之后。

因此，尽管在volatile写之前会有一个StoreStore屏障，但它的主要目的是为了保证写操作的顺序和可见性，而volatile写本身的内存屏障效应已经足以保证普通读操作不会与volatile写操作重排序。

---

3 volatile特性

3.1 保证可见性

保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见

• Code

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 修改完成");
    }
}

结论

        不加volatile，没有可见性，程序无法停止
        加了volatile，保证可见性，程序可以停止

Java内存模型中定义的8种每个线程自己的工作内存与主物理内存之间的原子操作

• read： 作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存
• load：作用于工作内存，将read从主内存传输的变量值放入工作内存变量副本中，即数据加载
• use：作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作
• assign：作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作
• store：作用于工作内存，将赋值完毕的工作变量的值写回给主内存
• write：作用于主内存，将store传输过来的变量值赋值给主内存中的变量

由于上述6条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁，所以，JVM提供了另外两个原子指令：

• lock：作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程
• unlock：作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用

---

3.2 没有原子性

volatile变量的符合操作不具有原子性

Code

package com.bilibili.juc.volatiles;

import java.util.concurrent.TimeUnit;

public class VolatileNoAtomicDemo {

    public static void main(String[] args) {

        MyNumber myNumber = new MyNumber();

        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    myNumber.add();
                }
            }, String.valueOf(i)).start();
        }

        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println(myNumber.n);

    }

}

class MyNumber {

    volatile int n;

    public void add() {
        n++;
    }

}

输出结果：
9861

        对于voaltile变量具备可见性，JVM只是保证从主内存加载到线程工作内存的值是最新的，也仅仅是数据加载时是最新的。但是多线程环境下，“数据计算”和“数据赋值”操作可能多次出现，若数据在加载之后，若主内存volatile修饰变量发生修改之后，线程工作内存的操作将会作废去读主内存最新值，操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步，进而导致数据不一致。由此可见volatile解决的是变量读时的可见性问题，但无法保证原子性，对于多线程修改主内存共享变量的场景必须加锁同步。

        数据加载、数据计算、数据赋值非原子操作，说明这三个步骤是可以被打断。原子性是指一个操作是不可被中断的。

        样例分析：按道理来说我们希望看到的结果应该是10000 (开了十个线程，每个线程对于n++)。但由于数据加载、数据计算、数据赋值这三部没有原子操作，就会导致比如说我某个线程刚给n++完，准备赋值了。但其他线程抢先运算完提交了，把最新数据刷新回主内存。这时候volatile关键字就会告诉当前线程，应该去中获取最新的变量n进行运算赋值。而上一次的写操作就丢失了！！！因此，结果会不满10000。

---

从n++的字节码角度说明

可以看到虽然代码中只有n++这一步操作，但底层被拆分成了三个步骤，并且这几个步骤之间没有加锁！没有原子性。

结论
        volatile变量不适合参与到依赖当前值的运算，如i++，i=i+1之类的

        那么依靠可见性的特点volatile可以用在哪些地方呢？

通常volatile用来保存某个状态的boolean值或者int值，《深入理解Java虚拟机》提到：

        由于volatile变量只能保证可见性，在不符合以下规则的运算场景中，我们仍然要通过加锁（使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：

• 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
• 变量不需要与其他的状态变量共同参与不变约束

---

面试回答
举一个volatile不具备原子性的案例。

举例i++的例子，在字节码文件中，i++分为三部，间隙期间不同步非原子操作

对于volatile变量，JVM只是保证从主内存加载到线程工作内存的值是最新的，也就是数据加载时是最新的，如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，也就造成了线程安全问题。

（中间这个蓝色框代表的是在执行引擎操作期间）

---

3.3禁止指令重排

说明与案例
重排序

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序

不存在数据依赖关系，可以重排序；

存在数据依赖关系 ，禁止重排序

但重排后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑！

重排序的分类和执行流程

编译器优化的重排序： 编译器在不改变单线程串行语义的前提下，可以重新调整指令的执行顺序
指令级并行的重排序： 处理器使用指令级并行技术来讲多条指令重叠执行，若不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序
内存系统的重排序： 由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是乱序执行

数据依赖性 ：若两个操作访问同一变量，且这两个操作中有一个为写操作，此时两操作间就存在数据依赖性。

案例

不存在数据依赖关系，可以重排序 ===> 重排序OK 。

存在数据依赖关系，禁止重排序===> 重排序发生，会导致程序运行结果不同。

编译器和处理器在重排序时，会遵守数据依赖性，不会改变存在依赖关系的两个操作的执行,但不同处理器和不同线程之间的数据性不会被编译器和处理器考虑，其只会作用于单处理器和单线程环境，下面三种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。

---

案例：

public class VolatileTest {
    int i = 0;
    volatile boolean flag = false;
    public void write(){
        i = 2;//假如不加volatile，这两句话的顺序就有可能颠倒，影像最终结果
        flag = true;
    }
    public void read(){
        if(flag){
            System.out.println("---i = " + i);
        }
    }
}

---

4 如何正确使用volatile

• 单一赋值可以，但是含复合运算赋值不可以（i++之类的）

• • volatile int a = 10;
  • volatile boolean flag = true;

• 状态标志，判断业务是否结束

• • 作为一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或任务结束

  • //这个前面讲过
    public class UseVolatileDemo
    {
        private volatile static boolean flag = true;
    
        public static void main(String[] args)
        {
            new Thread(() -> {
                while(flag) {
                    //do something......循环
                }
            },"t1").start();
    
            //暂停几秒钟线程
            try { TimeUnit.SECONDS.sleep(2L); } catch (InterruptedException e) { e.printStackTrace(); }
    
            new Thread(() -> {
                flag = false;
            },"t2").start();
        }
    }
    
    

• 开销较低的读，写锁策略
• • 当读远多于写，结合使用内部锁和volatile变量来减少同步的开销
  • 原理是：利用volatile保证读操作的可见性，利用synchronized保证符合操作的原子性

  • public class UseVolatileDemo
    {
        //
       // 使用：当读远多于写，结合使用内部锁和 volatile 变量来减少同步的开销
       // 理由：利用volatile保证读取操作的可见性；利用synchronized保证复合操作的原子性
         
        public class Counter
        {
            private volatile int value;
    
            public int getValue()
            {
                return value;   //利用volatile保证读取操作的可见性
                  }
            public synchronized int increment()
            {
                return value++; //利用synchronized保证复合操作的原子性
                   }
        }
    }
    

• DCL双端锁的发布

• • 问题描述：首先设定一个加锁的单例模式场景

public class SafeDoubleCheckSingleton
{
    private static SafeDoubleCheckSingleton singleton; //-----这里没加volatile
    //私有化构造方法
    private SafeDoubleCheckSingleton(){
    }
    //双重锁设计
    public static SafeDoubleCheckSingleton getInstance(){
        if (singleton == null){
            //1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象
            synchronized (SafeDoubleCheckSingleton.class){
                if (singleton == null){
                    //隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程读取
                    singleton = new SafeDoubleCheckSingleton();
                    //实例化分为三步
                    //1.分配对象的内存空间
                    //2.初始化对象
                    //3.设置对象指向分配的内存地址
                }
            }
        }
        //2.对象创建完毕，执行getInstance()将不需要获取锁，直接返回创建对象
        return singleton;
    }
}

• • • 在单线程环境下（或者说正常情况下），在“问题代码处（singleton = new SafeDoubleCheckSingleton();）”，会执行以下操作，保证能获取到已完成初始化的实例：

//三步
memory = allocate(); //1.分配对象的内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置对象指向分配的内存地址

• • • 隐患：在多线程环境下，在“问题代码处”，会执行以下操作，由于重排序导致2，3乱序，后果就是其他线程得到的是null而不是完成初始化的对象，其中第3步中实例化分多步执行（分配内存空间、初始化对象、将对象指向分配的内存空间），某些编译器为了性能原因，会将第二步和第三步重排序，这样某个线程肯能会获得一个未完全初始化的实例：

    • 

• • 多线程下的解决方案：加volatile修饰

public class SafeDoubleCheckSingleton
{
    //通过volatile声明，实现线程安全的延迟初始化。
    private volatile static SafeDoubleCheckSingleton singleton;
    //私有化构造方法
    private SafeDoubleCheckSingleton(){
    }
    //双重锁设计
    public static SafeDoubleCheckSingleton getInstance(){
        if (singleton == null){
            //1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象
            synchronized (SafeDoubleCheckSingleton.class){
                if (singleton == null){
                    //隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程读取
                                      //原理:利用volatile，禁止 "初始化对象"(2) 和 "设置singleton指向内存空间"(3) 的重排序
                    singleton = new SafeDoubleCheckSingleton();
                }
            }
        }
        //2.对象创建完毕，执行getInstance()将不需要获取锁，直接返回创建对象
        return singleton;
    }
}
 

        实例化singleton分多步执行（分配内存空间、初始化对象、将对象指向分配的内存空间），某些编译器为了性能原因，会将第二步和第三步进行重排序（分配内存空间、将对象指向分配的内存空间、初始化对象）。这样，某个线程可能会获得一个未完全初始化的实例。

        注意：这里是模拟单例环境，也就是说只有一个singleton实例化对象，因此特别怕获取到为null的实例（由于指令重排导致的情况）。所以才会加类锁把整个类锁起来。正常情况下 (正常多例情况，不会加类锁)

        这里多线程情况下，又是模拟单例环境，就可以会有可能多个线程几乎同上访问getInstance方法想获取一个实例对象，大家一看都还没创建出来。这时候一个线程刚开始分配内存空间，还没来得及初始化，另一个线程一看，已经有内存空间了，可能就跳过了第二步，把引用指向了null，导致获取到一个为null的实例！

---

        为什么多线程多例情况下不用考虑这个问题？

因为多例情况下，每个对象的创建都是在每个线程单独的工作区域中，就相当于单线程情况，自然就不可能出现。

在单线程环境中，Java虚拟机（JVM）的指令重排不会影响程序的执行结果，因为无论指令如何重排，最终的执行效果都是一致的。这是因为在单线程中，所有的操作都是按顺序执行的，不会受到其他线程的干扰。

然而，如果在多线程环境中，JVM的指令重排可能会导致程序的执行结果与预期不符。这是因为在多线程环境中，不同线程可能会并发地执行指令，如果JVM对这些指令进行了重排，可能会导致一些线程在其他线程完成关键操作之前就开始执行，从而导致程序出现错误。

---

5 本章最后的小总结

5.1 volatile可见性

volatile关键字保证可见性：	对一个被volatile关键字修饰的变量
1	写操作的话，这个变量的最新值会立即刷新回到主内存中
2	读操作的话，总是能够读取到这个变量的最新值，也就是这个变量最后被修改的值
3	当某个线程收到通知，去读取volatile修饰的变量的值的时候，线程私有工作内存的数据失效，需要重新回到主内存中去读取最新的数据。

5.2 volatile没有原子性

5.3 volatile禁重排

5.4 为什么我们Java写了一个volatile关键字，系统底层就加入内存屏障？两者的关系怎么联系？

        volatile关键字在字节码层面会被翻译为ACC_VOLATILE关键字，当底层系统读到这个关键字的时候就会自动加内存屏障。

5.5 内存屏障是什么？

        内存屏障：是一种 屏障指令，它使得CPU或编译器对屏障指令的前和后所发出的内存操作执行一个排序的约束。也称为内存栅栏或栅栏指令。

5.6 内存屏障能干吗？

●阻止屏障两边的指令重排序
●写操作时加入屏障，强制将线程私有工作内存的数据刷回主物理内存
●读操作时加入屏障，线程私有工作内存的数据失效，重新回到主物理内存中获取最新值

5.7 内存屏障四大指令

5.8 3句话总结

●volatile写之前的操作，都禁止重排序到volatile之后
●volatile读之后的操作，都禁止重排序到volatile之前
●volatile写之后volatile读，禁止重排序

标签：JUC,volatile,屏障,线程,内存,JMM,操作,排序
From： https://blog.csdn.net/qq_64064246/article/details/139270767