java并发编程实战(4) volatile实现原理四、volatile的适用场景

黄规速

发布于 2022-04-14 15:23:27

3110

发布于 2022-04-14 15:23:27

一、前言：volatile涉及线程安全的问题

package com.demo.springboot2.web.service;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * Created by huangguisu on 2021/1/1.
 */
import java.util.concurrent.CountDownLatch;
public class TestAdd {
    private volatile int count = 0;
    public static AtomicInteger atomicIntegerCount = new AtomicInteger(0);
    public void doAdd(CountDownLatch countDownLatch) {
        for (int i = 0; i < 4; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int j = 0; j < 1000; j++) {
                        count++;
                        atomicIntegerCount.incrementAndGet();
                    }
                    countDownLatch.countDown();
                }
            }).start();
        }
    }

    public int getCount() {
        return count;
    }

    public static void main(String[] args) {
        CountDownLatch countDownLatch = new CountDownLatch(4);
        TestAdd add = new TestAdd();
        add.doAdd(countDownLatch);
        try {
            countDownLatch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("volatile count:"+ add.getCount());
        System.out.println("atomicIntegerCount："+ atomicIntegerCount.get());

    }

}

运行结果：

count加上了volatile关键词，既然保证了可见性，为什么还是无法得到正确的结果：

原因是count++，并非原子操作，count++等效于如下步骤：

（1）、从主内存中读取count赋值给线程副本变量： temp=count

（2）、线程副本变量加1 ： temp=temp+1

（3）、线程副本变量写回主内存：count=temp

二、vlolatile的特性

一个volatile变量自身具有以下三个特性：

可见性：即当一个线程修改了声明为volatile变量的值，新值对于其他要读该变量的线程来说是立即可见的，即类似于一个通知机制，写回主内存的同时，通知线程内的变量。而普通变量是不能做到这一点的，普通变量的值在线程间传递需要通过主内存来完成。
有序性：volatile变量的所谓有序性也就是被声明为volatile的变量的临界区代码的执行是有顺序的，即禁止指令重排序。
受限原子性：这里volatile变量的原子性与synchronized的原子性是不同的，synchronized的原子性是指只要声明为synchronized的方法或代码块儿在执行上就是原子操作的。而volatile是不修饰方法或代码块儿的，它用来修饰变量，对于单个volatile变量的读/写操作都具有原子性，但类似于volatile++这种复合操作不具有原子性。所以volatile的原子性是受限制的。并且在多线程环境中，volatile并不能保证原子性。

volatile写-读的内存语义

volatile写的内存语义：当写线程写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。

volatile读的内存语义：当读线程读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存读取共享变量。

三、volatile实现原理

我们在java并发线程实战（1）线程安全和机制原理提到的CPU相关的专业术语：

内存屏障（memory barriers）：一组处理器指令，用于实现对内存操作的顺序限制。
缓存行（cache line）：CPU高速缓存中可以分配的最小存储单位。处理器填写缓存行时会加载整个缓存行。

1、volatile可见性实现原理

volatile可见性的内存语义是如何实现的呢？

下面我们看一段代码，并将代码生成的处理器的汇编指令打印出来（关于如何打印汇编指令，我会在文章末尾附上），看下对volatile变量进行写操作时，CPU会做什么事情：

public class VolatileTest {

    private static volatile VolatileTest instance = null;

    private VolatileTest(){}

    public static VolatileTest getInstance(){
        if(instance == null){
            instance = new VolatileTest();
        }

        return instance;
    }

    public static void main(String[] args) {
        VolatileTest.getInstance();
    }
}

以上的代码是一个我们非常熟悉的在多线程环境中不能保证线程安全的单例模式代码，这段代码中特殊的地方是，我将实例变量instance加上了volatile修饰，下面看打印的汇编指令：

上面截图中，我们看到我划线的一行的末尾有一句汇编注释：putstatic instance，了解JVM 字节码指令的小伙伴都知道，putstatic的含义是给一个静态变量设置值，在上述代码中也就是给静态变量instance赋值，对应代码：instance = new VolatileTest();在getInstance方法中为instance实例化，因为instance加了volatile修饰，所以给静态变量instance设置值也是在写一个volatile变量。

看到上述有汇编指令，也有字节码指令，大家会不会混淆这两种指令，这里我指明一下字节码指令和汇编指令的区别：

我们都知道java是一种跨平台的语言，那么java是如何实现这种平台无关性的呢？这就需要我们了解JVM和java的字节码文件。这里我们需要有一点共识，就是任何一门编程语言都需要转换为与平台相关的汇编指令才能够最终被硬件执行，比如C和C++都将我们的源代码直接编译成与CPU相关的汇编指令给CPU执行。不同系列的CPU的体系架构不同，所以它们的汇编指令也有不同，比如X86架构的CPU对应于X86汇编指令，arm架构的CPU对应于arm汇编指令。如果将程序源代码直接编译成与硬件相关的底层汇编指令，那么程序的跨平台性也就大打折扣，但执行性能相对较高。为了实现平台无关性，java的编译器javac并不是将java的源程序直接编译成与平台相关的汇编指令，而是编译成一种中间语言，即java的class字节码文件。字节码文件，顾名思义存的就是字节码，即一个一个的字节。有打开过java字节码文件研读过的小伙伴可能会发现，字节码文件里面存的并不是二进制，而是十六进制，这是因为二进制太长了，一个字节要由8位二进制组成。所以用十六进制标表示，两个十六进制就可以表示一个字节。java源码编译后的字节码文件是不能够直接被CPU执行的，那么该如何执行呢？答案是JVM，为了让java程序能够在不同的平台上执行，java官方提供了针对于各个平台的java虚拟机，JVM运行于硬件层之上，屏蔽各种平台的差异性。javac编译后的字节码文件统一由JVM来加载，最后再转化成与硬件相关的机器指令被CPU执行。知道了通过JVM来加载字节码文件，那么还有一个问题，就是JVM如何将字节码中的每个字节和我们写的java源代码相关联，也就是JVM如何知道我们写的java源代码对应于class文件中的哪段十六进制，这段十六进制是干什么的，执行了什么功能？并且一大堆的十六进制，我们也看不懂啊。所以这就需要定义一个JVM层面的规范，在JVM层面抽象出一些我们能够认识的指令助记符，这些指令助记符就是java的字节码指令。

再看上面的截图，当写instance这个volatile变量时，发现add前面加个一个lock指令，我在截图中框了出来，如何不加volatile修饰，是没有lock的。

lock指令在多核处理器下会引发下面的事件：

将当前处理器的缓存行的数据写回到系统内存，同时使其他CPU里缓存了该内存地址的数据置为无效。

为了提高处理速度，处理器一般不直接和内存通信，而是先将系统内存的数据读到内部缓存后再进行操作，但操作完成后并不知道处理器何时将缓存数据写回到内存。但如果对加了volatile修饰的变量进行写操作，JVM就会向处理器发送一条lock前缀的指令，将这个变量在缓存行的数据写回到系统内存。这时只是写回到系统内存，但其他处理器的缓存行中的数据还是旧的，要使其他处理器缓存行的数据也是新写回的系统内存的数据，就需要实现缓存一致性协议。即在一个处理器将自己缓存行的数据写回到系统内存后，其他的每个处理器就会通过嗅探在总线上传播的数据来检查自己缓存的数据是否已过期，当处理器发现自己缓存行对应的内存地址的数据被修改后，就会将自己缓存行缓存的数据设置为无效，当处理器要对这个数据进行修改操作的时候，会重新从系统内存中把数据读取到自己的缓存行，重新缓存。

总结下：volatile可见性的实现就是借助了CPU的lock指令，通过在写volatile的机器指令前加上lock前缀，使写volatile具有以下两个原则：

写volatile时处理器会将缓存写回到主内存。
一个处理器的缓存写回到内存会导致其他处理器的缓存失效。

2、volatile有序性的实现原理

volatile有序性的保证就是通过禁止指令重排序来实现的。指令重排序包括编译器和处理器重排序，JMM会分别限制这两种指令重排序。

那么禁止指令重排序又是如何实现的呢？答案是加内存屏障。JMM为volatile加内存屏障有以下4种情况：

在每个volatile写操作的前面插入一个StoreStore屏障，防止写volatile与后面的写操作重排序。
在每个volatile写操作的后面插入一个StoreLoad屏障，防止写volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadLoad屏障，防止读volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadStore屏障，防止读volatile与后面的写操作重排序。

上述内存屏障的插入策略是非常保守的，比如一个volatile的写操作后面需要加上StoreStore和StoreLoad屏障，但这个写volatile后面可能并没有读操作，因此理论上只加上StoreStore屏障就可以，的确，有的处理器就是这么做的。但JMM这种保守的内存屏障插入策略能够保证在任意的处理器平台，volatile变量都是有序的。

1.对volatile变量进行写操作时，会在写操作后加入一条store屏障指令，将本地内存中的共享变量值刷新到主存中。 2.对volatile变量进行读操作时，会在读操作前加入一条load屏障指令，从主存中读取共享变量。

3.JSR-133对volatile内存语义的增强

在JSR-133之前的旧的java内存模型中，虽然不允许对volatile变量之间的操作进行重排序，但允许对volatile变量与普通变量之间进行重排序。比如内存屏障前面是一个写volatile变量的操作，内存屏障后面的操作是一个写普通变量的操作，即使这两个写操作可能会破坏volatile内存语义，但JMM是允许这两个操作进行重排序的。

在JSR-133以及后面的新的java内存模型中，增强了volatile的内存语义。只要volatile变量与普通变量之间的重排序可能会破坏volatile的内存语义，这种重排序就会被编译器重排序规则和处理器内存屏障出入策略禁止。

附：配置idea打印汇编指令工具包下载地址：链接：https://pan.baidu.com/s/11yRnsOHca5EVRfE9gAuVxA 将下载的工具包解压，复制到jdk安装目录的jre路径下的bin目录中，如图：

然后配置idea，在 VM options 选项中输入：-server -Xcomp -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=compileonly,*类名.方法名 JRE选项选择已放入工具包的jre路径。下图是我的idea配置：

以上配置好后运行就可以打印汇编指令了。

四、volatile的适用场景

https://www.jianshu.com/p/5584600d2569

模式 1：状态标志

也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如分布式事务

http://seata.io/zh-cn/docs/user/quickstart.html

例如完成初始化或请求停机。

volatile boolean shutdownRequested;
...
public void shutdown() { 
    shutdownRequested = true; 
}

public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}

线程1执行doWork()的过程中，可能有另外的线程2调用了shutdown，所以boolean变量必须是volatile。

而如果使用 synchronized 块编写循环要比使用 volatile 状态标志编写麻烦很多。由于 volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。

这种类型的状态标记的一个公共特性是：通常只有一种状态转装换； shutdownRequested 标志从false 转换为true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从false 到true，再转换到false）。此外，还需要某些原子状态转换机制，例如原子变量。

模式 2：一次性安全发布（one-time safe publication）

在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。

这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象。

//注意volatile！！！！！！！！！！！！！！！！！    
private volatile static Singleton instace;     

public static Singleton getInstance(){     
   //第一次null检查       
   if(instance == null){              
	synchronized(Singleton.class) {    //1       
	//第二次null检查         
	    f(instance == null){          //2    
		instance = new Singleton();//3    
	    }    
	}             
    }    
    return instance; 
}

如果不用volatile，则因为内存模型允许所谓的“无序写入”，可能导致失败。——某个线程可能会获得一个未完全初始化的实例。

考察上述代码中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 instance 来引用此对象。这行代码的问题是：在Singleton 构造函数体执行之前，变量instance 可能成为非 null 的！ 什么？这一说法可能让您始料未及，但事实确实如此。

在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设上述代码执行以下事件序列：

线程 1 进入 getInstance() 方法。
由于 instance 为 null，线程 1 在 //1 处进入synchronized 块。
线程 1 前进到 //3 处，<u>但在构造函数执行之前，使实例成为非null</u>。
线程 1 被线程 2 预占。
线程 2 检查实例是否为 null。因为实例不为 null，线程 2 将instance 引用返回，返回一个构造完整但部分初始化了的Singleton 对象。
线程 2 被线程 1 预占。
线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。

模式 3:独立观察（independent observation）

安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。【例如】假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

使用该模式的另一种应用程序就是收集程序的统计信息。【例】如下代码展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用lastUser 引用来发布值，以供程序的其他部分使用。

public class UserManager {  
    public volatile String lastUser; //发布的信息  

    public boolean authenticate(String user, String password) {  
        boolean valid = passwordIsValid(user, password);  
        if (valid) {  
            User u = new User();  
            activeUsers.add(u);  
            lastUser = user;  
        }  
        return valid;  
    }  
}

模式 #4：“volatile bean” 模式

volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。

在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通——即不包含约束！

@ThreadSafe  
public class Person {  
    private volatile String firstName;  
    private volatile String lastName;  

    public String getFirstName() { return firstName; }  
    public String getLastName() { return lastName; }  

    public void setFirstName(String firstName) {   
        this.firstName = firstName;  
    }  

    public void setLastName(String lastName) {   
        this.lastName = lastName;  
    }

模式 #5：开销较低的“读－写锁”策略

如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。

如下显示的线程安全的计数器，使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

@ThreadSafe  
public class CheesyCounter {  
  // Employs the cheap read-write lock trick  
  // All mutative operations MUST be done with the 'this' lock held  
   @GuardedBy("this") private volatile int value;  

    //读操作，没有synchronized，提高性能  
    public int getValue() {   
        return value;   
    }   

    //写操作，必须synchronized。因为x++不是原子操作  
    public synchronized int increment() {  
        return value++;  
    }  
}

使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2018/01/23 ，如有侵权请联系 cloudcommunity@tencent.com 删除

编程算法