volatile关键字详解

感谢传智播客老师的深入细致讲解

 

一  volatile 关键字

1.1. 多线程下变量的不可见性

1.1.1 概述

在多线程并发执行下，多个线程修改共享的成员变量，会出现一个线程修改了共享变量的值后，另一个线程不能直接看到该线程修改后的变量的最新值。

1.1.2 案例演示

public class MyThread extends Thread {
    // 定义成员变量
    private boolean flag = false ;
    public boolean isFlag() { return flag;}
    @Override
    public void run() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
    }
    // 将flag的值更改为true
    this.flag = true ;
    System.out.println("flag=" + flag);
   }
}
public class VolatileThreadDemo {// 测试类
     public static void main(String[] args) {
         // 创建MyThread线程对象
         Thread t = new MyThread() ;
         t.start();
         // main方法
         while(true) {
             if(t.isFlag()) {
             System.out.println("执行了======");
         }
      }
   }
}

 

我们看到，子线程中已经将 flag 设置为 true ，但 main()方法中始终没有读到修改后的最新值，从而循环没有能进入到语句中执行，所以没有任何打印。

1.1.3 小结

多线程下修改共享变量会出现变量修改值后的不可见性。

 

1.2 变量不可见性内存语义

1.2.1 概述

Java 内存模型（和 Java 并发编程有关的模型）：JMM 。 是 java 虚拟机规范中所定义的一种内存模型， Java 内存模型是标准化的，屏蔽掉了底层不同计算机的区别。

Java 内存模型 (Java Memory Model) 描述了 Java 程序中各种变量 ( 线程共享变量 ) 的访问规则，以及在 JVM 中将变量 存储到内存和从内存中读取变量这样的底层细节。

JMM 有以下规定：

所有的共享变量都存储于主内存。这里所说的变量指的是实例变量和类变量。不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。

每一个线程还存在自己的工作内存，线程的工作内存，保留了被线程使用的变量的工作副本。

线程对变量的所有的操作 ( 读，取 ) 都必须在工作内存中完成，而不能直接读写主内存中的变量。

不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存中转来完成。

本地内存和主内存的关系：

1. 子线程 t 从主内存读取到数据放入其对应的工作内存

2. 将 flflag 的值更改为 true ，但是这个时候 flflag 的值还没有写回主内存

3. 此时 main 方法读取到了 flflag 的值为 false

4. 当子线程 t 将 flflag 的值写回去后，但是 main 函数里面的 while(true) 调用的是系统比较底层的代码，速度快，快到

没有时间再去读取主存中的值，

所以 while(true) 读取到的值一直是 false 。 ( 如果有一个时刻 main 线程从主内存中读取到了主内存中 flflag 的最新

值，那么 if 语句就可以执行， main 线程何时从主内存中读取最新的值，我们无法控制 )

1.2.3 小结

可见性问题的原因

所有共享变量存在于主内存中，每个线程由自己的本地内存，而且线程读写共享数据也是通过本地内存交换的，所以才导致了可见性问题。

 

1.3. 变量不可见性解决方案

1.3.1 概述

如何实现在多线程下访问共享变量的可见性：也就是实现一个线程修改变量后，对其他线程可见呢？

两种方案：

第一种是加锁，第二种是使用 volatile 关键字

1.3.2 解决方案

加锁

// main方法 
while(true) { 
    synchronized (t) { 
        if(t.isFlag()){ 
            System.out.println("主线程进入循环执行~~~~~"); 
       } 
    } 
}

某一个线程进入 synchronized 代码块前后，执行过程入如下：

a. 线程获得锁

b. 清空工作内存

c. 从主内存拷贝共享变量最新的值到工作内存成为副本

d. 执行代码

e. 将修改后的副本的值刷新回主内存中

f. 线程释放锁

volatile 关键字修饰

使用 volatile 关键字修改该变量

private volatile boolean flag ;

 

1. 子线程 t 从主内存读取到数据放入其对应的工作内存

2. 将 flflag 的值更改为 true ，但是这个时候 flflag 的值还没有写会主内存

3. 此时 main 方法 main 方法读取到了 flflag 的值为 false

4. 当子线程 t 将 flflag 的值写回去后，失效其他线程对此变量副本

5. 再次对 flflag 进行操作的时候线程会从主内存读取最新的值，放入到工作内存中

总结： volatile 保证不同线程对共享变量操作的可见性，也就是说一个线程修改了 volatile 修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。

1.3.3 小结

volatile 修饰的变量可以在多线程并发修改下，实现线程间变量的可见性。

 

二  volatile 的其他特性

2.1 volatile 特性概述

volatile 总体概览

除了 volatile 可以保证可见性外， volatile还具备如下一些突出的特性：

volatile 的原子性问题 ： volatile 不能保证原子性操作。

禁止指令重排序： volatile 可以防止指令重排序操作。

2.2 volatile 不保证原子性

所谓的原子性是指在一次操作或者多次操作中，要么所有的操作全部都得到了执行并且不会受到任何因素的干扰而中断，要么所有的操作都不执行。volatile 不保证原子性。

2.1.1 问题案例演示

public class VolatileAtomicThread implements Runnable { 
    // 定义一个int类型的遍历 
    private int count = 0 ; 
    @Override public void run() { 
        // 对该变量进行++操作，100次 
        for(int x = 0 ; x < 100 ; x++) { 
            count++ ; 
            System.out.println("count =========>>>> " + count); 
        } 
    } 

}
public class VolatileAtomicThreadDemo { 
    public static void main(String[] args) { 
        // 创建VolatileAtomicThread对象 
        VolatileAtomicThread volatileAtomicThread = new VolatileAtomicThread() ; 
        // 开启100个线程对count进行++操作 
        for(int x = 0 ; x < 100 ; x++) { 
            new Thread(volatileAtomicThread).start();
        } 
    } 
}

执行结果：不保证一定是 10000

2.1.2 问题原理说明

以上问题主要是发生在 count++ 操作上：

count++ 操作包含 3 个步骤：

从主内存中读取数据到工作内存

对工作内存中的数据进行 ++ 操作

将工作内存中的数据写回到主内存

count++ 操作不是一个原子性操作，也就是说在某一个时刻对某一个操作的执行，有可能被其他的线程打断。

2.1.3 小结

在多线程环境下， volatile 关键字可以保证共享数据的可见性，但是并不能保证对数据操作的原子性（在多线程环境下volatile 修饰的变量也是线程不安全的）。

在多线程环境下，要保证数据的安全性，我们还需要使用锁机制。

2.1.4 问题解决

使用锁机制

我们可以给 count++ 操作添加锁，那么 count++ 操作就是临界区的代码，临界区只能有一个线程去执行，所以count++就变成了原子操作。

原子类

概述： java 从 JDK1.5 开始提供了 java.util.concurrent.atomic 包 ( 简称 Atomic 包 ) ，这个包中的原子操作类提供了一种用法简单，性能高效，线程安全地更新一个变量的方式。

AtomicInteger

原子型 Integer ，可以实现原子更新操作

    public class VolatileAtomicThread implements Runnable { 
        // 定义一个int类型的变量 
        private AtomicInteger atomicInteger = new AtomicInteger() ; 
        @Override public void run() { 
            // 对该变量进行++操作，100次 
            for(int x = 0 ; x < 100 ; x++) { 
                int i = atomicInteger.getAndIncrement(); 
                System.out.println("count =========>>>> " + i); 
            } 
        } 
    }

 

2.3 禁止指令重排序

2.3.1 概述

什么是重排序 ：为了提高性能，编译器和处理器常常会对既定的代码执行顺序进行指令重排序。

原因：一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标而进行奋斗：在不改变程序执行结果的前提下，尽可能提高执行效率。JMM 对底层尽量减少约束，使其能够发挥自身

优势。因此，在执行程序时， 为了提高性能，编译器和处理器常常会对指令进行重排序 。一般重排序可以分为如下三种：

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序；

2. 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果 不存在数据依赖性 ，处理器

可以改变语句对应机器指令的执行顺序；

3. 内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。

2.3.2 重排序的好处

重排序可以提高处理的速度。

2.3.3 重排序问题案例演示

引入 ：重排序虽然可以提高执行的效率，但是在并发执行下， JVM 虚拟机底层并不能保证重排序下带来的安全性等问题，请看如下案例：

    public class OutOfOrderExecution { 
        private static int i = 0, j = 0; 
        private static int a = 0, b = 0; 
        public static void main(String[] args) throws InterruptedException { 
            int count = 0; 
            // 计数 
            while(true) { 
                count++; 
                i = 0; 
                j = 0; 
                a = 0; 
                b = 0; 
                Thread one = new Thread(new Runnable() {
                    @Override public void run() { 
                        a = 1; i = b; 
                    } 
                }); 
                Thread two = new Thread(new Runnable() { 
                    @Override public void run() { 
                        b = 1; j = a; 
                    } 
                }); 
                two.start(); 
                one.start(); 
                one.join(); 
                two.join(); 
                String result = "第" + count + "次（ i= " + i + ", j= " + j + ")"; 
                if (i == 0 && j == 0) {
                    System.out.println(result); break; 
                } else { 
                    System.out.println(result); 
                } 
            } 
        } 
    }

以上程序中的 4 行代码的执行顺序决定了 最终 i 和 j 的值 ，在执行的过程中可能会 出现三种 情况如下：

1. a = 1 ; i=b(0) ; b = 1 ; y = a(1) ， 最终

2. b = 1 ; j=a(0) ; a = 1 ; i = b(1) ， 最终

3. b = 1 ; a=1 ; i = b(1) ; j = a(1) ， 最终

但是有一种情况大家可能是没有发现的，经过测试如下：

在某一次中出現了i=0,j=0的情况

按照以前的观点 ：代码执行的顺序是不会改变的，也就第一个线程是 a=1 是在 i=b 之前执行的，第二个线程 b=1 是在 j=a之前执行的。

发生了重排序 ：在线程 1 和线程 2 内部的两行代码的 实际执行顺序 和代码在 Java 文件中的顺序是不一致的，代码指令并不是严格按照代码顺序执行的，他们的顺序改变了，这样就是发生了重排序，这里颠倒的 是 a = 1 ,i = b 以及 j=a , b=1 的顺序，从而发生了指令重排序。直接获取了 i = b(0) , j = a(0) 的值！显然这个值是不对的。

2.3.4 volatile 禁止重排序

volatile 修饰变量后可以实现禁止指令重排序！

2.3.5 小结

使用 volatile 可以禁止指令重排序，从而修正重排序可能带来的并发安全问题。

 

三  volatile 内存语义

3.1 volatile 写读建立的 happens-before 关系

3.1.1 概述

上面的内容讲述了重排序原则，为了提高处理速度， JVM 会对代码进行编译优化 ，也就是指令重排序优化，并发编程下指令重排序会带来一些安全隐患：如指令重排序导致的多个线程操作之间的不可见性 。如果让程序员再去了解这些

底层的实现以及具体规则，那么程序员的负担就太重了，严重影响了并发编程的效率。 从JDK 5 开始，提出了 happens-before 的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before 关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。 所以为了解决多线程的可见性问题，就搞出了happens-before 原则，让线程之间遵守这些原则。编译器还会优化我们的语句，所以等于是给了编译器优化的约束。不能让它优化的不知道东南西北了！

简单来说： happens-before 应该翻译成：前一个操作的结果可以被后续的操作获取。讲白点就是前面一个操作变量a赋值为 1 ，那后面一个操作肯定能知道 a 已经变成了 1 。

3.1.2 happens-before 规则

具体的一共有六项规则：

1. 程序顺序规则（单线程规则）

解释：一个线程中的每个操作， happens-before 于该线程中的任意后续操作同一个线程中前面的所有写操作对后面的操作可见

2. 锁规则（ Synchronized,Lock 等）

解释：对一个锁的解锁， happens-before 于随后对这个锁的加锁。

如果线程 1 解锁了 monitor a ，接着线程 2 锁定了 a ，那么，线程 1 解锁 a 之前的写操作都对线程 2 可见（线程1和线程 2 可以是同一个线程）

3. volatile 变量规则 ：

解释：对一个 volatile 域的写， happens-before 于任意后续对这个 volatile 域的读。

如果线程 1 写入了 volatile 变量 v （临界资源），接着线程 2 读取了 v ，那么，线程 1 写入 v 及之前的写操作都 对线程 2 可见（线程 1 和线程 2 可以是同一个线程）

4. 传递性 ：

解释：如果 A happens-before B ，且 B happens-before C ，那么 A happens-before C 。

A h-b B ， B h-b C 那么可以得到 A h-b C

5. start() 规则：

解释：如果线程 A 执行操作 ThreadB.start() （启动线程 B ），那么 A 线程的 ThreadB.start() 操作 happens-before于线程 B 中的任意操作。

假定线程 A 在执行过程中，通过执行 ThreadB.start() 来启动线程 B ，那么线程 A 对共享变量的修改在接下来线程B 开始执行前对线程 B 可见。注意：线程 B 启动之后，线程 A 在对变量修改线程 B 未必可见

6. join() 规则

解释：如果线程 A 执行操作 ThreadB.join() 并成功返回，那么线程 B 中的任意操作 happens-before 于线程 A 从ThreadB.join()操作成功返回。

线程 t1 写入的所有变量，在任意其它线程 t2 调用 t1.join() ，或者 t1.isAlive() 成功返回后，都对 t2 可见

3.1.3 volatile 写读建立的 happens-before 规则

happens-before 有一个原则是：如果 A 是对 volatile 变量的写操作， B 是对同一个变量的读操作，那么 hb(A,B)

    public class VisibilityHP { 
        int a = 1; 
        int b = 2; 
        private void write() { 
            a = 3; b = a; 
        }
        private void read() { 
            System.out.println("b=" + b + ";a=" + a);
        }
        public static void main(String[] args) { 
            while (true) { 
                VisibilityHP test = new VisibilityHP(); 
                new Thread(new Runnable() { 
                    @Override public void run() { 
                        test.write(); 
                    } 
                }).start(); 
                new Thread(new Runnable() { 
                    @Override public void run() { 
                        test.read(); 
                    } 
                }).start(); 
            } 
        } 
    }

分析以上案例存在四种执行情况：

b=3;a=3

b=2;a=1

b=2;a=3

第四种情况（低概率）是：没给 b 加 volatile, 那么有可能出现 a=1 , b = 3 。因为 a 虽然被修改了，但是其他线程不可见，而b 恰好其他线程可见，造成了 b=3 , a=1 。

如何解决第四种情况题呢？

按照 happens-before 规则，我们只需要给 b 加上 volatile ，那么 b 之前的写入（ a = 3; ）将对读取 b 之后的代码可见,也就是说即使a 不加 volatile, 只要 b 读取到 3 ，那么 b 之前的操作（ a=3 ）就一定是可见的，此时就绝对不会出现 b=3 的时候而读取到a=1 了。

3.1.4 volatile 重排序规则小结

volatile 重排序规则：

写 volatile 变量时，无论前一个操作是什么，都不能重排序

读 volatile 变量时，无论后一个操作是什么，都不能重排序

当先写 volatile 变量，后读 volatile 变量时，不能重排序

 

四  volatile 总结

4.1 long 和 double 的原子性

概述

在 java 中， long 和 double 都是 8 个字节共 64 位 ( 一个字节 =8bit) ，那么如果是一个 32 位的系统，读写 long 或 double 的变量时会涉及到原子性问题，因为32 位的系统要读完一个 64 位的变量，需要分两步执行，每次读取 32 位，这样就对 double和 long 变量的赋值就会出现问题：

如果有两个线程同时写一个变量内存，一个进程写低 32 位，而另一个写高32位，这样将导致获取的 64 位数据是失效的数据。

结论 ：如果是在 64 位的系统中，那么对 64 位的 long 和 double 的读写都是原子操作的。即可以以一次性读写 long 或 double的整个 64bit 。如果在 32 位的 JVM 上， long 和 double 就不是原子性操作了。

解决方法：需要使用 volatile 关键字来防止此类现象

对于 64 位的 long 和 double ，如果没有被 volatile 修饰，那么对其操作可以不是原子的。在操作的时候，可以分成两步，每次对32 位操作。

如果使用 volatile 修饰 long 和 double ，那么其读写都是原子操作在实现JVM 时，可以自由选择是否把读写 long 和 double 作为原子操作； java中对于 long 和 double 类型的写操作不是原子操作，而是分成了两个 32 位的写操作。读操作是否也分成了两

个 32 位的读呢？在 JSR-133 之前的规范中，读也是分成了两个 32 位的读，但是从 JSR-133 规范开始，即 JDK5 开始，读操作也都具有原子性；

java 中对于其他类型的读写操作都是原子操作 ( 除 long 和 double 类型以外 ) ； 对于引用类型的读写操作都是原子操作，无论引用类型的实际类型是32 位的值还是 64 位的值； Java商业虚拟机已经解决了 long 和 double 的读写操作的原子性。

4.2 volatile 在双重检查加锁的单例中的应用

 

    public class Singleton {
        // 静态属性，volatile保证可见性和禁止指令重排序
        private volatile static Singleton instance = null;
        private Singleton6(){} 
        public static Singleton getInstance(){ 
            // 第一重检查锁定 
            if(instance==null){ 
                // 同步锁定代码块 
                synchronized(Singleton.class){ 
                    //第二重检查锁定 
                    if(instance==null){ 
                        // 注意：非原子操作 
                        instance=new Singleton(); 
                    } 
                } 
            }
            return instance; 
        } 
    }

4.3 volatile 的使用场景

4.3.1 纯赋值操作

volatile 不适合做 a++ 等操作。 适合做纯赋值操作 : 如 boolean flag = false/true;

4.3.2 触发器

按照 volatile 的可见性和禁止重排序以及 happens-before 规则， volatile 可以作为刷新之前变量的触发器。我们可以将某个变量设置为volatile 修饰，其他线程一旦发现该变量修改的值后，触发获取到的该变量之前的操作都将是最新的 且可见。

 

4.4 volatile 与 synchronized

4.4.1 区别

volatile 只能修饰实例变量和类变量，而 synchronized 可以修饰方法，以及代码块。

volatile 保证数据的可见性，但是不保证原子性 ( 多线程进行写操作，不保证线程安全 ); 而 synchronized 是一种排他（互斥）的机制。

volatile 用于禁止指令重排序：可以解决单例双重检查对象初始化代码执行乱序问题。

volatile 可以看做是轻量版的 synchronized,volatile 不保证原子性，但是如果是对一个共享变量进行多个线程的赋值，而没有其他的操作，那么就可以用volatile 来代替 synchronized, 因为赋值本身是有原子性的，而 volatile又保证了可见性，所以就可以保证线程安全了。

 

4.5 volatile 的总结

内存可见性、不保证原子性、禁止指令重排

1. volatile 修饰符适用于以下场景 : 某个属性被多个线程共享 , 其中有一个线程修改了此属性 , 其他线程可以立即得到修改后的值, 比如 boolean flflag ; 或者作为触发器 , 实现轻量级同步。

2. volatile 属性的读写操作都是无锁的 , 它不能替代 synchronized , 因为它没有提供原子性和互斥性。因为无锁 , 不需要花费时间在获取锁和释放锁_ 上 , 所以说它是低成本的。

3. volatile 只能作用于属性 , 我们用 volatile 修饰属性 , 这样 compilers 就不会对这个属性做指令重排序。

4. volatile 提供了可见性 , 任何一个线程对其的修改将立马对其他线程可见。 volatile 属性不会被线程缓存 , 始终从主存中读取。

5. volatile 提供了 happens-before 保证 , 对 volatile 变量 v 的写入 happens- before 所有其他线程后续对 v 的读操作。

6. volatile 可以使得 long 和 double 的赋值是原子的。

7. volatile 可以在单例双重检查中实现可见性和禁止指令重排序，从而保证安全性。