美文网首页干货分享
吃透Java并发:volatile是怎么保证可见性的

吃透Java并发:volatile是怎么保证可见性的

作者: 小白菜aaa | 来源:发表于2020-09-17 16:44 被阅读0次

    前言

    volatile关键字能够保证可见性和有序性,但是volatile为什么能够保证可见性和有序性?为什么volatile又不能保证原子性?
    今天,我们从CPU多核缓存架构出发,结合MESI缓存一致性协议来深入剖析一下,volatile的原理。

    问题的出现

    我们先通过一个例子来看看,可见性导致的线程安全问题:

    public class Main {
    
        static int a = 0;
    
        public static void main(String[] args)  throws Exception {
            Thread t1 = new Thread(new Runnable() {
                @Override
                public void run() {
                    while (a == 0) {
    
                    }
                    System.out.println("T1得知a = 1");
                }
            });
    
            Thread t2 = new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(1000);
                        a = 1;
                        System.out.println("T2修改a = 1");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            });
            t1.start();
            t2.start();
        }
    }
    
    

    线程T2再休眠1秒之后,修改了a的值为1,此时T1应该退出while循环并打印,但是结果并非如此:

    T1没有退出循环,程序也就不会结束。但是如果对a使用volatile关键字修饰就会解决该问题。

    这个问题的源头就在于可见性问题。为什么会出现这种问题呢?这里我们需要从CPU多核缓存架构讲起。

    CPU多核缓存架构

    一个双核CPU架构可以如下图所示:

    首先需要明确的一点是,计算机实际上是分为多级缓存的,因为读取缓存的数据性能十分快

    1. 当CPU1需要读取共享变量的值a时,首先会找缓存(即L1、L2、L3三级高速缓存),看看这个值是不是在L1。
    2. 很明显,缓存没办法给CPU1它想要的数据,于是只能去主内存读取共享变量的值
    3. 缓存得到共享变量的值之后,把数据交给寄存器,但是缓存留了个心眼,它把a的值存了起来,这样下次别的线程再需要a的值时,就不用再去主内存问了

    至此,一次完整的数据访问流程走完了。L1和L2、L3都是高速缓存,从高速缓存和主内存读取数据的速度完全是两个概念。所以才会有主内存和缓存的设计。

    写数据时刷新内存

    针对上述模型,当CPU1读取完数据后,假如对数据进行了修改,那么它会将缓存 —> 主内存的顺序将修改后的数据刷新一遍,完成对数据的更新。

    从读到写这一整个流程看起来似乎都是完美的,而且每次修改都把数据重新写回到主内存,讲道理不会有问题啊?

    实际上问题正是出在这个看似完美的读写操作中:对于CPU1来说的确是完美的,但如果这时候CPU2来插一脚呢?我们思考下面这个流程:

    1. CPU1读取数据a=1,CPU1的缓存中都有数据a的副本
    2. CPU2也执行读取操作,同样CPU2也有数据a=1的副本
    3. CPU1修改数据a=2,同时CPU1的缓存以及主内存a=2
    4. CPU2再次读取a,但是CPU2在缓存中命中数据,此时a=1

    问题到这里已经很明显了,CPU2并不知道CPU1改变了共享变量的值,因此造成了不可见问题。

    缓存一致性协议

    为了解决这个问题,在早期的CPU当中,是通过在总线上直接加锁的形式来解决缓存不一致的问题。

    但是正如Java中Synchronized一样,直接加锁太粗暴了,由于在锁住总线期间,其他CPU无法访问内存,导致效率低下。很明显这样做是不可取的。

    所以就出现了缓存一致性协议。缓存一致性协议有MSI,MESI,MOSI,Synapse,Firefly及DragonProtocol等等。

    MESI协议

    最出名的就是Intel 的MESI协议,MESI协议保证了每个缓存中使用的共享变量的副本是一致的。

    1. Modify(修改):当缓存行中的数据被修改时,该缓存行置为M状态
    2. Exclusive(独占):当只有一个缓存行使用某个数据时,置为E状态
    3. Shared(共享):当其他CPU中也读取某数据到缓存行时,所有持有该数据的缓存行置为S状态
    4. Invalid(无效):当某个缓存行数据修改时,其他持有该数据的缓存行置为I状态

    它核心的思想是:当CPU写数据时,如果发现操作的变量是共享变量,即在其他CPU中也存在该变量的副本,会发出信号通知其他CPU将该变量的缓存行置为无效状态,因此当其他CPU需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取。

    而这其中,监听和通知又基于总线嗅探机制来完成。

    总线嗅探机制

    嗅探机制其实就是一个监听器,回到我们刚才的流程,如果是加入MESI缓存一致性协议和总线嗅探机制之后:

    1. CPU1读取数据a=1,CPU1的缓存中都有数据a的副本,该缓存行置为(E)状态
    2. CPU2也执行读取操作,同样CPU2也有数据a=1的副本,此时总线嗅探到CPU1也有该数据,则CPU1、CPU2两个缓存行都置为(S)状态
    3. CPU1修改数据a=2,CPU1的缓存以及主内存a=2,同时CPU1的缓存行置为(S)状态,总线发出通知,CPU2的缓存行置为(I)状态
    4. CPU2再次读取a,虽然CPU2在缓存中命中数据a=1,但是发现状态为(I),因此直接丢弃该数据,去主内存获取最新数据

    当我们使用volatile关键字修饰某个变量之后,就相当于告诉CPU:我这个变量需要使用MESI和总线嗅探机制处理。从而也就保证了可见性。

    指令重排序

    在加入MESI和总线嗅探机制后,当CPU2发现当前缓存行数据无效时,会丢弃该数据,并前往主内存获取最新数据。

    但是这里又会产生一个问题:CPU1把数据刷回主内存是需要时间的,假如CPU2在主内存拿数据时,CPU1还没有把数据刷回来呢?

    很明显,CPU2不会把资源浪费在这里傻等。它会先跳过和该数据有关的语句,继续处理后面的逻辑。

    比如说如下代码:

    a = 1;
    b = 2;
    b++;
    
    

    假如第一条语句需要等待CPU1数据刷新,那么CPU2可能就会先回来执行后面两条语句。因为对于CPU2来说,先执行后面两条语句不会对最终结果造成任何影响。

    但是多线程环境下就会出现问题。关于指令重排序,我们放到内存屏障来讲。

    一些可能让你困惑的问题

    依旧是一开始的代码,假如我们把TI线程循环的内容改成如下:

    Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            while (a == 0) {
                System.out.println(a);
            }
            System.out.println("T1得知a = 1");
        }
    });
    
    

    或者如下:

    Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            while (a == 0) {
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            System.out.println("T1得知a = 1");
        }
    });
    
    

    此时变量a没有使用volatile修饰。

    但是运行结果会让你匪夷所思:程序正常结束,a变量对T1居然可见了!

    while在作怪?

    这是为什么呢?难道是因为在while循环中加了代码导致的?

    那我们加个变量b再来试试:

    Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            while (a == 0) {
                b++;
            }
            System.out.println("T1得知a = 1");
        }
    });
    
    

    这次运行结果T1又没办法感知a的变化了,也就是说,并不是while中有代码就会发生可见的现象。

    那么真正的原因究竟是什么呢?

    勤奋的CPU

    这是一个很有趣的现象,有些人认为是因为println方法加了synchronized的原因。的确,锁机制保证了每次执行都会把共享内存中的数据同步到工作内存中。

    但Thread.sleep方法并没有加呀?

    真正的原因在于,CPU是很勤奋的,如果它发现自己有空闲的时间,就会主动去主内存里更新自己缓存中的数据。

    而Thread.sleep方法对于CPU来说,会给它“喘息”的时间,让它有空去把缓存里的数据去主内存刷新一下。

    而后面的b++操作几乎没有给CPU任何机会休息,也就没办法去刷新缓存中的数据信息。

    总结

    事实上,我们的JMM模型就是类比CPU多核缓存架构的,它的作用是屏蔽掉了底层不同计算机的区别
    JMM不是真实存在的,只是一个抽象的概念。volatile也是借助MESI缓存一致性协议和总线嗅探机制才得以完成
    此外,当CPU不支持缓存一致性协议时,还是需要依靠总线加锁的形式来保证线程安全
    本文到这里就结束了,感谢大家看到最后,记得点赞加关注哦,如有不对之处还请多多指正。

    相关文章

      网友评论

        本文标题:吃透Java并发:volatile是怎么保证可见性的

        本文链接:https://www.haomeiwen.com/subject/pevtyktx.html