并发bug之源(二)-有序性

什么是有序性?

简单来说,假设你写了下面的程序:

int a = 1;
int b = 2;
System.out.println(a);
System.out.println(b);

但经过编译器/CPU优化(指令重排序,和编程语言无关)后可能就变成了这样:

int b = 2; 
int a = 1;
System.out.println(a);
System.out.println(b);

当然上面例子这种情况,就算调整了代码顺序,也没有任何影响。但实际工作过程中,这种擅自优化,并不总是没有问题的,在多线程情况下,有时候就会给我们的程序中埋下一个隐藏的bug。

如何证明指令重排序的存在?

我说有指令重排序就有啊,那不得拿出证据来?

这个证明有点复杂,我先写一个程序,跑起来看结果,然后再解释:

public class DisOrder {

    private static int a, b, x, y = 0;

    public static void main(String[] args) throws InterruptedException {
        for (long i = 0; i < Long.MAX_VALUE; i++) {
            a = 0;b = 0;x = 0;y = 0;
            CountDownLatch cdl = new CountDownLatch(2);
            Thread t1 = new Thread(() -> {
                a = 1;
                x = b;
                cdl.countDown();
            });
            Thread t2 = new Thread(() -> {
                b = 1;
                y = a;
                cdl.countDown();
            });
            t1.start();
            t2.start();
            cdl.await();
            
            if (x == 0 && y == 0) {
                System.out.println("第" + i + "次循环时, (" + x + "," + y + ")");
                break;
            }
        }
    }

}

跑这个程序需要等一会,执行结果:

《并发bug之源(二)-有序性》

我来解释下这个程序在干什么,程序中有四个成员变量 a, b, x, y ,初始都是0。然后执行一个无限循环,循环中启动两个线程,两个线程分别去修改 a, b, x, y 四个变量,一共有四行代码:

a = 1;
x = b;
b = 1;
y = a;

每次修改完成后,判断下x和y是否都为0,是则打印 x, y 并停止循环,否则重新循环,并将四个变量归零。

现在我们来简单推理下,假设程序严格按照代码的顺序去执行,那么两个线程修改完成后,a, b, x, y 的值有哪些可能呢?

我猜你懒得推理,直接说结论吧,这里我使用一张马士兵老师的图:

《并发bug之源(二)-有序性》

结果一共有6种可能性,一种为x=0,y=1,一种为x=1,y=0,另外四种都为x=1,y=1,可以发现,没有任何情况的结果是x=0,y=0的。

但是,我们从上面程序实际执行结果可以看到,循环终止了,也打印出了当第35239次循环时,x=0,y=0。那么也就是说,必然发生了上面6种可能性以外的其他情况。大家可以再简单推理下,发生什么情况会导致 x=0,y=0 呢?

我猜你还是懒得推理,直接上图:

《并发bug之源(二)-有序性》

我们发现只有这2种情况,会导致x=0,y=0。而从这两种情况可以发现,代码执行的顺序,和我们写的顺序发生了交换,第一个线程里原本是a = 1;x = b;,在这两种情况里,都变成了x = b;a = 1;,第二个线程里也是如此。由此可以证明,指令重排序的存在。

下面我们来看个经典的面试题

DCL单例到底需不需要加 volatile

DCL(Double Check Lock)双重检查锁,单例模式的一种实现方案,代码如下:

public class Singleton {

    private static Singleton instance;

    private Singleton() {}

    public static Singleton getSingleton() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

}

这段代码看起来很完美,但它是有问题的。主要在于instance = new Singleton()这句,这其实并非是一个原子操作,事实上这行代码大概做了下面 3 件事情:

  1. 分配一块内存M,成员变量赋默认值(0,0.0,false,null)
  2. 调用 Singleton 类的构造函数,在内存M上初始化成员变量
  3. 将instance变量指向分配的内存M(执行完这步 instance 就为非 null 了)

但是由于存在指令重排序的优化,上面的第二步和第三步的顺序是不能保证的,最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是1-3-2,则就有可能在 3 执行完毕、2 未执行之前,被线程二抢占了CPU,去调用 getSingleton() 方法。这时 instance 已经是非 null 了(但却没有执行第二步的初始化,此时只是完成第一步的半初始化状态),所以线程二会直接返回 instance,然后使用,然后理所当然发生错误。因为此时 instance 对象还没有执行第二步 ,没有调用构造函数初始化成员变量。

这里给大家看下 new 一个对象,字节码长什么样,证实一下确实是这三个步骤,可不是我胡说:

《并发bug之源(二)-有序性》

图中红色框起来的三行字节码指令,就是上面对应的三个步骤( dup 和 return 指令在这里暂时不需要关注)。

0 new #2 <java/lang/Object>
4 invokespecial #1 <java/lang/Object.<init> : ()V>
7 astore_1

那么这个问题要怎么解决呢?其实只要将变量 instance ⽤ volatile 修饰,就可以避免这个问题了。

public class Singleton {

    /** 声明成 volatile */
    private volatile static Singleton instance;

    private Singleton() {}

    public static Singleton getSingleton() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

}

可另一个问题又来了,为什么加了 volatile ,就可以避免指令重排序导致的问题呢?

volatile 如何防止指令重排序

我们想一下,发生上面指令重排序的情况,本质上就是两行代码的顺序发生了交换。比如你站在A点,我站在B点,你我交换位置就会出现问题。那如果不想让你我交换位置,有什么办法呢?给咱俩中间加一堵墙就行了嘛,你过不来,我也过不去,就不会发生位置交换了。没错,其实 volatile 就是这么干的,这堵“墙”,就被称之为内存屏障

内存屏障,其本质上是一条特殊的屏障指令,编译器/CPU当看到这条指令的时候,就绝对不会将这条指令之前的指令,和之后的指令换顺序。

那屏障指令有哪些呢?不同的CPU,是不一样的。我们以英特尔CPU举例,它的屏障指令有3个:lfence、mfence、sfence。这个东西是汇编级别的,我是学Java的,暂时不用关心这些。

那Java里面有没有屏障指令呢?Java里也得有一种机制,来告诉JVM,不能随便换顺序啊。没错,这语句就是volatile

JVM在看到 volatile 之后呢,就会给被 volatile 修饰的变量加屏障指令。注意这里和缓存一致性协议没有关系,缓存一致性协议是硬件级别的东西,我们现在讲的是 Java 虚拟机中的实现。

JVM中的内存屏障一共有四种,这是JVM的规范:

  1. LoadLoad屏障
  2. StoreStore屏障
  3. LoadStore屏障
  4. StoreLoad屏障

看着有点懵,其实很简单。

以第一个LoadLoad屏障为例,有个一个变量X,它前面有人读它,它后面也有人读它,中间有个LoadLoad屏障,那么前面的Load和后面的Load就不能换顺序。

再比如第二个StoreStore屏障,有个一个变量X,它前面有人写它,它后面也有人写它,中间有个StoreStore屏障,那么前面的Store和后面的Store就不能换顺序。

好了后面的两个指令就不用讲了吧。

那么就可以看volatile是怎么实现的了,在JVM层面:

对于被volatile修饰的变量,在发生写的前面,会加上StoreStore屏障,在后面会加上StoreLoad屏障。

《并发bug之源(二)-有序性》

对于被volatile修饰的变量,在发生读的后面,会加上LoadLoad屏障,和LoadStore屏障。

《并发bug之源(二)-有序性》

这样就从JVM上保证了读写的有序性。

好了,今天就到这里,下次有空再聊聊最难的原子性。

    原文作者:dijia478
    原文地址: https://www.cnblogs.com/dijia478/p/16901314.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞