二、并发编程之volatile详解

ゝ一世哀愁。 2022-11-21 11:46 237阅读 0赞

### 并发编程的可见性，原子性与有序性问题 ###

**原子性**  
原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会 被其他线程影响。

在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于 32位系统的来说，long类型数据和double类型数据(对于基本数据类型， byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如 果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对 于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32 位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变 量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变 量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原 子操作来执行，因此对于这个问题不必太在意，知道这么回事即可。

X=10; //原子性(简单的读取、将数字赋值给变量) Y = x; //变量之间的相互赋值，不是原子操作
    X++; //对变量进行计算操作
    X = x+1;

**可见性**  
理解了指令重排现象后，可见性容易了，可见性指的是当一个线程修改了某个共享变量的 值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的，因为 我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改 过的新值。

但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程 拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享 变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但 此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象 就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分 析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程 序轮序执行的问题，从而也就导致可见性问题。

**有序性**  
有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样 的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现 象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未 必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多 线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保 证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象。

### volatile ###

**原子性问题**  
除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized和 Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。**volatile不能保证原子性**

**可见性问题**  
volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被 其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取 新值。synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能 访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。

**有序性问题**  
在Java里面，可以通过volatile关键字来保证一定的“有序性”(具体原理在下一节讲述 volatile关键字)。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized 和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就 保证了有序性。  
Java内存模型:每个线程都有自己的工作内存(类似于前面的高速缓存)。线程对变量的 所有操作都必须在工作内存中进行，而不能直接对主存进行操作。并且每个线程不能访问其他 线程的工作内存。Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得 到保证的有序性，这个通常也称为happens-before 原则。如果两个操作的执行次序无法从 happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它 们进行重排序。  
指令重排序:java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与 它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排 序。指令重排序的意义是什么?JVM能根据处理器特性(CPU多级缓存系统、多核处理器等) 适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

**下图为从源码到最终执行的指令序列示意图**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center]  
**as-if-serial**  
as-if-serial语义的意思是:不管怎么重排序(编译器和处理器为了提高并行度)，(单线 程)程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因 为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被 编译器和处理器重排序。

**happens-before原则**  
只靠sychronized和volatile关键字来保证原子性、可见性以及有序性，那么编写并发程序 可能会显得十分麻烦，幸运的是，从JDK 5开始，Java使用新的JSR-133内存模型，提供了 happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数 据是否存在竞争、线程是否安全的依据，happens-before 原则内容如下：

1.  程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行。
2.  volatile规则 volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单 的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当 该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能 够看到该变量的最新值。
3.  线程启动规则 线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的 start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量 的修改对线程B可见
4.  传递性 A先于B ，B先于C 那么A必然先于C
5.  线程终止规则 线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前 执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法 成功返回后，线程B对共享变量的修改将对线程A可见。
6.  线程中断规则 对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中 断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。
7.  对象终结规则 对象的构造函数执行，结束先于finalize()方法
8.  锁规则 解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说， 如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。

**volatile内存语义**  
volatile是Java虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用

*  保证被volatile修饰的共享变量对所有线程总数可见的，也就是当一个线程修改了一  
    个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知
 *  禁止指令重排序优化。

**volatile的可见性**  
关于volatile的可见性作用，我们必须意识到被volatile修饰的变量对所有线程总数立即可见的，对volatile变量的所有写操作总是能立刻反应到其他线程中

public class VolatileVisibilitySample {
        
        private volatile boolean initFlag = false;
        static Object object = new Object();
    
        public void refresh(){
        
            this.initFlag = true; //普通写操作，(volatile写)
            String threadname = Thread.currentThread().getName();
            System.out.println("线程："+threadname+":修改共享变量initFlag");
        }
    
        public void load(){
        
            String threadname = Thread.currentThread().getName();
            int i = 0;
            while (!initFlag){
        
                synchronized (object){
        
                    i++;
                }
                //i++;
            }
            System.out.println("线程："+threadname+"当前线程嗅探到initFlag的状态的改变"+i);
        }
    
        public static void main(String[] args){
        
            VolatileVisibilitySample sample = new VolatileVisibilitySample();
            Thread threadA = new Thread(()->{
        
                sample.refresh();
            },"threadA");
    
            Thread threadB = new Thread(()->{
        
                sample.load();
            },"threadB");
    
            threadB.start();
            try {
        
                 Thread.sleep(2000);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
            threadA.start();
        }
    
    }

打印结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 1]  
threadA改变了initFlag的值，threadB马上感知到

**volatile无法保证原子性**

public class VolatileAtomicSample {
        
    
        private volatile static int counter = 0;
    
        public static void main(String[] args) {
        
            for (int i = 0; i < 10; i++) {
        
                Thread thread = new Thread(()->{
        
                    for (int j = 0; j < 1000; j++) {
        
                        counter++; //不是一个原子操作,第一轮循环结果是没有刷入主存，这一轮循环已经无效
                        //1 load counter 到工作内存
                        //2 add counter 执行自加
                        //其他的代码段？
                    }
                });
                thread.start();
            }
    
            try {
        
                Thread.sleep(1000);
            } catch (InterruptedException e) {
        
                e.printStackTrace();
            }
    
            System.out.println(counter);
        }
    
    }

打印结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 2]  
如果能保证原子性，打印的结果应该是10000，但是这里是没有的，说明volatile是不能保证原子性的，这里涉及到了MESI缓存一致性协议的竞争丢弃，后面会详细讲

**volatile禁止重排优化**  
volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱序  
执行的现象，关于指令重排优化前面已详细分析过，这里主要简单说明一下volatile是如何实 现禁止指令重排优化的。先了解一个概念，内存屏障(Memory Barrier)。

内存屏障，又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执行 顺序，二是保证某些变量的内存可见性(利用该特性实现volatile的内存可见性)。由于编译 器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器 和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏 障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷出 各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。总之， volatile变量正是通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。下面看一 个非常典型的禁止重排优化的例子DCL，如下:

public class DoubleCheckLock {
        
    
        private static DoubleCheckLock instance;
    
        public static DoubleCheckLock getInstance() {
        
            if (instance == null) {
        
                synchronized (Singleton.class) {
        
                    if (instance == null) {
        
                    	// 多线程环境下可能会出现问题的地方
                        instance = new DoubleCheckLock();
                    }
                }
            }
            return instance;
        }

上述代码一个经典的单例的双重检测的代码，这段代码在单线程环境下并没有什么问题， 但如果在多线程环境下就可以出现线程安全问题。原因在于某一个线程执行到第一次检测，读 取到的instance不为null时，instance的引用对象可能没有完成初始化。

因为instance = new DoubleCheckLock();可以分为以下3步完成(伪代码)

memory = allocate();//1.分配对象内存空间 
    instance(memory);//2.初始化对象
    instance = memory;//3.设置instance指向刚分配的内存地址，此时 instance!=null

由于步骤1和步骤2间可能会重排序，如下:

memory=allocate();//1.分配对象内存空间 
    instance=memory;//3.设置instance指向刚分配的内存地址，此时instance! =null，但是对象还没有初始化完成!
    instance(memory);//2.初始化对象

由于步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单 线程中并没有改变，因此这种重排优化是允许的。但是指令重排只会保证串行语义的执行的一 致性(单线程)，但并不会关心多线程间的语义一致性。所以当一条线程访问instance不为null 时，由于instance实例未必已初始化完成，也就造成了线程安全问题。那么该如何解决呢，很 简单，我们使用volatile禁止instance变量被执行指令重排优化即可。

// 禁止指令重排序优化
    private volatile static DoubleCheckLock instance;

**volatile内存语义的实现**  
前面提到过重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。  
下图是JMM针对编译器制定的volatile重排序规则表。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 3]  
举例来说，第三行最后一个单元格的意思是:在程序中，当第一个操作为普通变量的读或 写时，如果第二个操作为volatile写，则编译器不能重排序这两个操作。  
从上图可以看出:  
当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保 volatile写之前的操作不会被编译器重排序到volatile写之后。  
∙当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保 volatile读之后的操作不会被编译器重排序到volatile读之前。  
∙当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。  
为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来 禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数 几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略  
在每个volatile写操作的前面插入一个StoreStore屏障。  
在每个volatile写操作的后面插入一个StoreLoad屏障。  
在每个volatile读操作的后面插入一个LoadLoad屏障。  
在每个volatile读操作的后面插入一个LoadStore屏障。  
上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。

**下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 4]  
上图中StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任意 处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主 内存。

这里比较有意思的是，volatile写后面的StoreLoad屏障。此屏障的作用是避免 volatile写与 后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在 一个volatile写的后面 是否需要插入一个StoreLoad屏障(比如，一个volatile写之后方 法立即return)。为了保证能正确 实现volatile的内存语义，JMM在采取了保守策略: 在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。从整 体执行效率的角度考虑，JMM最终选择了在每个 volatile写的后面插入一个StoreLoad 屏障。因为volatile写-读内存语义的常见使用模式是:一个 写线程写volatile变量，多 个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写 之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM 在实现上 的一个特点:首先确保正确性，然后再去追求执行效率。

**下图是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 5]  
上图中LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore 屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。  
上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不 改变 volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。下面通过 具体的示例

public class VolatileBarrierExample {
        
        int a;
        volatile int m1 = 1;
        volatile int m2 = 2;
    
        void readAndWrite() {
        
            int i = m1;   // 第一个volatile读
            int j = m2;   // 第二个volatile读
    
            a = i + j;    // 普通写
    
            m1 = i + 1;   // 第一个volatile写
            m2 = j * 2;   // 第二个 volatile写
        }
    
    }

**针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 6]  
注意，最后的StoreLoad屏障不能省略。因为第二个volatile写之后，方法立即 return。此时编 译器可能无法准确断定后面是否会有volatile读或写，为了安全起见， 编译器通  
常会在这里插 入一个StoreLoad屏障。

上面的优化针对任意处理器平台，由于不同的处理器有不同“松紧度”的处理器内 存模 型，内存屏障的插入还可以根据具体的处理器内存模型继续优化。以X86处理器为 例，图中除最后的StoreLoad屏障外，其他的屏障都会被省略。

前面保守策略下的volatile读和写，在X86处理器平台可以优化成如下图所示。前文 提到过，X86处理器仅会对写-读操作做重排序。X86不会对读-读、读-写和写-写操作 做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。在X86中， JMM仅需 在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存 语义。这意味着在 X86处理器中，volatile写的开销比volatile读的开销会大很多(因为 执行StoreLoad屏障开销会比较大)。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 7]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/700405f6bcb44291826dfedd23e07333.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20201102000148674.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201102000040856.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20201102004330365.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20201102004908832.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20201102005027481.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 6]: https://img-blog.csdnimg.cn/20201102110600991.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw_size_16_color_FFFFFF_t_70_pic_center 7]: https://img-blog.csdnimg.cn/20201102005557993.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NTEzNDMw,size_16,color_FFFFFF,t_70#pic_center