硬件级别详解Volatile关键字的可见性

本文将从硬件级别深入探讨Synchronized和volatile关键字的特性。之前的文章中已经提到过：

文章参考：

对线面试官 - Synchronize Volatile | 通俗易懂的白话文讲解其原理实现

面试官：你知道为什么volatile无法保证原子性，只能保证可见性和有序性吗？

派大星：关于volatile关键字对原子性的保障在Java中是非常有限的，几乎可以忽略不计。比如在32位的Java虚拟机中，对long和double变量的赋值操作不是原子性的，此时可以通过给变量加上volatile关键字来保证在32位Java虚拟机中对long和double的赋值操作是原子性的。相比之下，int i = 0的原子性是Java语言规范（例如Oracle）所规定的。

面试官：不错，那么为什么long和double在32位Java虚拟机中的简单赋值操作不是原子性的呢？

派大星：所有变量的简单赋值操作，Java语言规范都保证其原子性。但例外的是long和double在32位虚拟机中的简单赋值操作不是原子性的。因为long和double是64位的。如果多线程同时并发执行long = 30，由于long是64位的，就会导致有的线程在修改long的高32位，有的线程在修改long的低32位，多线程并发给long类型的变量进行赋值操作，在32位虚拟机中是有问题的。产生的结果导致变量的值不是30，可能是-3333334430，也就是乱码一样的数字，因为高低32位赋值错误，导致二进制转换为十进制之后是一个很奇怪的数字。

面试官：可以从硬件级别谈一下可见性问题吗？或者说硬件级别为什么会有可见性问题？

派大星：好的。可以从以下几种情况分析：

每个处理器都有自己的寄存器（register），所以多个处理器各自运行一个线程时，会将主内存中的某个变量副本加载到寄存器中，然后对其进行更新。这样就会导致各个线程无法看到其他处理器中的变量值修改。因此引发了可见性的第一个问题：寄存器级别的变量副本的更新，无法让其他处理器看到。还有一个问题是，处理器运行的线程对变量的操作针对的是写缓存（store buffer），而不是直接更新主内存，所以很可能导致一个线程更新了变量，但仅仅只是在写缓存中进行了更新，并没有直接更新到主内存中去。这时其他线程也就无法读取到它的写缓冲区中的变量值。因此也导致了可见性的问题。每个处理器都有自己的高速缓存，处理器运行的线程对变量的操作可能更新到写缓冲器中，也可能更新到高速缓存中或者是主内存中。但其他处理器还是从自己的高速缓存或写缓冲器中读取的变量值，此时还是读取的旧值，而不是新值。

面试官：既然硬件级别是有可见性问题的，那么是如何解决的呢？

派大星：硬件级别要想实现可见性，其中一个方法就是通过MESI协议。这个MESI协议在之前的文章中也有提过，但并没有展开说。根据具体底层硬件的不同，MESI协议的实现也是有些区别的。

面试官：可以简单说说MESI的实现方式吗？

派大星：可以的，MESI协议的实现如下：一个处理器将另一个处理器的高速缓存中的更新后的数据拿到自己的高速缓存中来更新，这样彼此之间的缓存就实现了同步，然后各个处理器之间的线程看到的变量数据也就是一致的了。当然，为了实现MESI协议，其中有两个配套的专业机制：flush处理器缓存和refresh处理器缓存。

首先说一下flush处理器缓存，其目的是将自己更新的变量值刷新到高速缓存中（或主内存中），并且它还会发送一个消息到总线（bus），通知其他处理器某个变量值被它更新了。这样才可以让其他处理器从自己的高速缓存（或主内存）中读取到更新的值。其次就是refresh处理器缓存，它的目的是处理器中的线程在读取一个变量时，如果发现总线（bus）嗅探中有消息说其他处理器的线程更新了该变量的值，则必须从其他处理器的高速缓存（或主内存）中读取到这个最新的值，并更新到自己的高速缓存中去。总的来说，为了保证可见性，在底层是通过MESI协议、flush处理器缓存和refresh处理器缓存这一套机制来保障的。并且，内存屏障的使用，在底层硬件级别的原理，其实就是在执行flush和refresh。

面试官：那这次就先聊到这里吧，后续咱们可以再从硬件级别聊聊指令重排序的问题。

派大星：好的。