多线程的指令重排问题:as-if-serial语义,happens-before语义;volatile关键字,volatile和synchronized的区别


一、指令重排问题


你写的代码有可能,根本没有按照你期望的顺序执行,因为编译器和 CPU 会尝试指令重排来让代码运行更高效,这就是指令重排。

1.1 虚拟机层面

我们都知道CPU执行指令的时候,访问内存的速度远慢于 CPU 速度

为了尽可能减少内存操作带来的 CPU 空置的影响,虚拟机会按照自己的一些规则将程序编写顺序打乱:即写在后面的代码在时间顺序上可能会先执行,而写在前面的代码会后执行。

当然这样的前提是不会产生错误。不管谁先开始,总之后面的代码在一些情况下存在先结束的可能。

1.2 硬件层面

在硬件层面,CPU会将接收到的一批指令按照其规则重排序,同样是基于 CPU 速度比缓存速度快的原因。

和上一点的目的类似,只是硬件处理的话,每次只能在接收到的有限指令范围内重排序,而虚拟机可以在更大层面、更多指令范围内重排序。

1.3 数据依赖

如果两个操作访问的是同一个变量且其中有一个是写操作,那么这两个操作之间就存在数据依赖

数据依赖分为读后写、写后写、写后读。

读后写:a = b;b = 1;
写后读:a = 1;b = a;
写后写:a = 1;a = 2;

上面这几种情况,存在数据以来,当存在数据依赖的时候,重排指令就会造成程序结果错误,所以编译器和处理器会遵循数据依赖,不改变顺序。

1.4 As-If-Serial语义

基于上面的重排序原则,不管怎么重排序(编译器和处理器为了提高并行度),(单线程)程序的执行结果不能被改变

编译器,runtime 和处理器都必须遵守 as-if-serial 语义。为了遵守 as-if-serial 语义,编译器和处理器不会对存在数据依赖关系的操作做重排序,因为这种重排序会改变执行结果。

1.5 Happens-Before语义

直接翻译就是,在之前发生,本质上和 as-if-serial 一样的。

定义:如果一个操作 happens-before 另一个操作,那么意味着第一个操作的结果对第二个操作可见,而且第一个操作的执行顺序将排在第二个操作的前面。

如果重排序之后的结果,与按照happens-before关系来执行的结果一致,那么这种重排序并不非法(也就是说,JMM允许这种重排序)。

具体规则如下:

  • 程序顺序规则:一个线程中的每个操作,happens-before于该线程中的任意后续操作。
  • 监视器锁规则:对一个锁的解锁,happens-before于随后对这个锁的加锁。
  • volatile变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。
  • 线程启动规则:如果线程A执行操作ThreadB.start()(启动线程B),那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
  • 线程终结规则:如果线程A执行操作ThreadB.join()并成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
  • 传递性规则:如果A happens-before B,且B happens-before C,那么A happens-before C。

总结:

这么些规则总的来说就在体现一件事,也就是单线程里,程序有关的各个层面都会做指令重排的优化,而且会用这些规则来保证结果正确。


二、多线程的指令重排


如果是多线程,无法保证正确性,指令重排可能会造成结果错误。

我个人是这样理解的:多线程最大问题就是一个 先来后到 可能破坏正确性的问题,因此有同步、加锁等等机制来保障先来后到,可是指令重排让线程本身的指令乱了,就可能让整体的结果功亏一篑。

一个简单的例子:

/**
* 指令重排问题
*/
public class HappenBefore {
    private static int i = 0, j = 0;
    private static int a = 0, b = 0;
    public static void main(String[] args) throws InterruptedException {
        while (true){
            i = 0;
            j = 0;
            a = 0;
            b = 0;
            Thread t1 = new Thread(()->{
                a = 1;
                i = b;
            });
            Thread t2 = new Thread(()->{
                b = 1;
                j = a;
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println("i = " + i +" ; j = " + j);
            if (i == 0 && j == 0){
                break;
            }
        }
    }
}

上面程序里开了两个线程,交替赋值;join保障这两个线程都在 main 线程之前执行完,确保最后在执行完后输出。(注意并不是保证 t1 在 t2 之前执行)

线程t1 线程t2
a = 1; b = 1;
i = b; j = a;

如果没有指令重排,按照我们的分析,多线程情况下,t1 和 t2 分别执行完,或者经过cpu的调度,t1 和 t2 线程经过了切换,那么可能出现的情况是,最终的 i 和 j 为:

  • i = 0,j = 1;(t1先执行完)
  • i = 1,j = 0;(t2先执行完)
  • i = 1,j = 1;(中间线程切换了)

但是结果应该是不会出现 i = 0,j = 0 的情况的。

可是代码跑起来就会发现,会出现 i = 0,j = 0 的情况,这就是指令重排在多线程情况下带来的问题。在各自单线程里,因为没有依赖关系,所以编译器、虚拟机以及 cpu 可以进行乱序重排,最后导致了这种结果。


三、volatile 关键字


Volatile 英文翻译:易变的、可变的、不稳定的。

  1. 在之前的示例中,线程不安全的问题,我们使用线程同步,也就是通过 synchronized 关键字,对操作的对象加锁,屏蔽了其他线程对这块代码的访问,从而保证安全。
  2. 这里的 volatile 尝试从另一个角度解决这个问题,那就是保证变量可见,有说法将其称之为轻量级的synchronized

volatile保证变量可见:简单来说就是,当线程 A 对变量 X 进行了修改后,在线程 A 后面执行的其他线程能够看到 X 的变动,就是保证了 X 永远是最新的。

更详细的说,就是要符合以下两个规则:

  1. 线程对变量进行修改后,要立刻写回主内存;
  2. 线程对变量读取的时候,要从主内存读,而不是缓存。

另一个角度,结合指令重排序,volatile 修饰的内存空间,在这上面执行的指令是禁止乱序的因此,在单例模式的 DCL 写法中,volatile 也是必须的元素。

3.1 volatile使用示例1

private static int num = 0;
public static void main(String[] args) throws InterruptedException {
    new Thread(()->{
        while (num == 0){

        }
    }).start();

    Thread.sleep(1000);
    num = 1;
}

代码死循环,因为主线程里的 num = 1,不能及时将数据变化更新到主存,因此上面的代码 while 条件持续为真。

因此可以给变量加上 volatile:

private volatile static int num = 0;

这样就在执行几秒后就会停止运行。

3.2 单例模式Double Checked Locking

在设计模式里的单例模式,如果在多线程的情况下,仍然要保证始终只有一个对象,就要进行同步和锁。

class DCL{
    private static volatile DCL instance;
    private DCL(){

    }

    public static DCL getInstance(){
        if (instance == null){//check1
            synchronized (DCL.class){
                if (instance == null){//check2
                    instance = new DCL();
                }
            }
        }
        return instance;
    }
}

双重校验锁,实现线程安全的单例锁。

关于单例模式的内容,指路:单例模式讲解及8种写法

但是:volatile不能保证原子性。

3.3 原子性问题

原子操作就是这个操作要么执行完,要么不执行,不可能卡在中间。

比如在 Java 里, i = 2,这个指令是具有原子性的,而 i++ 则不是,事实上 i++ 也是先拿 i,再修改,再重新赋值给 i 。

例如你让一个volatile的integer自增(i++),其实要分成3步:

1)读取volatile变量值到local;
2)增加变量的值;
3)把local的值写回,让其它的线程可见。

这 3 步的jvm指令为:

mov    0xc(%r10),%r8d ; Load
inc    %r8d           ; Increment
mov    %r8d,0xc(%r10) ; Store
lock addl $0x0,(%rsp) ; StoreLoad Barrier

最后一步是内存屏障

什么是内存屏障?内存屏障告诉CPU和编译器先于这个命令的必须先执行,后于这个命令的必须后执行,同时强制更新一次不同CPU的缓存,也就是通过这个操作,使得 volatile 关键字达到了所谓的变量可见性。

这个时候我们就知道,如果一个操作有好几步,如果其他的线程修改了值,将会都产生覆盖,还是会出现不安全的情况,所以, volatile 关键字本身无法保证原子性。

volatile 无法保证原子性。我们还是用两数之和来示例:

public class NoAtomic {
    private static volatile int num = 0;
    public static void main(String[] args) throws InterruptedException {
        for (int i=0; i<100; i++){
            new Thread(()->{
                for (int j=0; j < 100; j++){
                    num++;
                }
            }).start();
        }
    Thread.sleep(3000);
    System.out.println(num);
    }
}

输出结果会小于预期,虽然 volatile 保证了可见性,但是却不能保证操作的原子性。因此想要保证原子性,还是得回去找 synchronized 或者使用juc下的原子数据类型。

3.4 volatile 和 synchronized 的区别

  • volatile 本质是在告诉 jvm 当前变量在寄存器(工作内存)中的值是不确定的,需要从主存中读取; synchronized 则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住。
  • volatile 仅能使用在变量级别;synchronized则可以使用在变量、方法、和类级别的。
  • volatile 仅能实现变量的修改可见性,不能保证原子性;而 synchronized 则可以保证变量的修改可见性和原子性。
  • volatile 不会造成线程的阻塞;synchronized 可能会造成线程的阻塞。

不过:由于硬件层面,从工作内存到主存的更新速度已经提升的很快,加上 synchronized 的改进,也已经不用考虑太过重量的问题,所以 volatile 很少使用。

posted @ 2020-08-20 10:59  Life_Goes_On  阅读(791)  评论(0编辑  收藏  举报