目录：
1.数据依赖性
2.程序顺序规则
3.重排序对多线程的影响
4.编译器重排序
5.指令集并行的重排序
6.内存系统的重排序
7.memory barrier
8.JDK 1.7 内存屏障实现

1.数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型：

| 名称 | 代码示例 | 说明 |
| 写后读 | a = 1;b = a; | 写一个变量之后，再读这个位置。 |
| 写后写 | a = 1;a = 2; | 写一个变量之后，再写这个变量。 |
| 读后写 | a = b;b = 1; | 读一个变量之后，再写这个变量。 |

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。

前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。

注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial 语义

as-if-serial 语义的意思指：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守 as-if-serial 语义。

为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作可能被编译器和处理器重排序。为了具体说明，请看下面计算圆面积的代码示例：

double pi  = 3.14;    //A
double r   = 1.0;     //B
double area = pi * r * r; //C  

上面三个操作的数据依赖关系如下图所示：

image

如上图所示，A 和 C 之间存在数据依赖关系，同时 B 和 C 之间也存在数据依赖关系。因此在最终执行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的结果将会被改变）。但 A 和 B 之间没有数据依赖关系，编译器和处理器可以重排序 A 和 B 之间的执行顺序。下图是该程序的两种执行顺序：

image

as-if-serial 语义把单线程程序保护了起来，遵守 as-if-serial 语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial 语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

2.程序顺序规则

根据 happens- before 的程序顺序规则，上面计算圆的面积的示例代码存在三个 happens- before 关系：

1. A happens- before B；

2. B happens- before C；

3. A happens- before C；

这里的第3个 happens- before 关系，是根据 happens- before 的传递性推导出来的。

这里 A happens- before B，但实际执行时 B 却可以排在 A 之前执行（看上面的重排序后的执行顺序）。在第一章提到过，如果 A happens- before B，JMM 并不要求 A 一定要在 B 之前执行。JMM 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。这里操作 A 的执行结果不需要对操作 B 可见；而且重排序操作 A 和操作 B 后的执行结果，与操作 A 和操作 B 按 happens- before 顺序执行的结果一致。在这种情况下，JMM 会认为这种重排序并不非法（not illegal），JMM 允许这种重排序。

在计算机中，软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，尽可能的开发并行度。编译器和处理器遵从这一目标，从 happens- before 的定义我们可以看出，JMM 同样遵从这一目标。

3.重排序对多线程的影响

现在让我们来看看，重排序是否会改变多线程程序的执行结果。请看下面的示例代码：

class ReorderExample {
int a = 0;
boolean flag = false;

public void writer() {
    a = 1;                   //1
    flag = true;             //2
}

Public void reader() {
    if (flag) {                //3
        int i =  a * a;        //4
        ……
    }
}
}  

flag 变量是个标记，用来标识变量 a 是否已被写入。这里假设有两个线程 A 和 B，A 首先执行writer() 方法，随后 B 线程接着执行 reader() 方法。线程B在执行操作4时，能否看到线程 A 在操作1对共享变量 a 的写入？

答案是：不一定能看到。

由于操作1和操作2没有数据依赖关系，编译器和处理器可以对这两个操作重排序；同样，操作3和操作4没有数据依赖关系，编译器和处理器也可以对这两个操作重排序。让我们先来看看，当操作1和操作2重排序时，可能会产生什么效果？请看下面的程序执行时序图：

image

如上图所示，操作1和操作2做了重排序。程序执行时，线程A首先写标记变量 flag，随后线程 B 读这个变量。由于条件判断为真，线程 B 将读取变量a。此时，变量 a 还根本没有被线程 A 写入，在这里多线程程序的语义被重排序破坏了！

※注：本文统一用红色的虚箭线表示错误的读操作，用绿色的虚箭线表示正确的读操作。

下面再让我们看看，当操作3和操作4重排序时会产生什么效果（借助这个重排序，可以顺便说明控制依赖性）。下面是操作3和操作4重排序后，程序的执行时序图：

image

在程序中，操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程 B 的处理器可以提前读取并计算 a*a，然后把计算结果临时保存到一个名为重排序缓冲（reorder buffer ROB）的硬件缓存中。当接下来操作3的条件判断为真时，就把该计算结果写入变量i中。

从图中我们可以看出，猜测执行实质上对操作3和4做了重排序。重排序在这里破坏了多线程程序的语义！

在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是 as-if-serial 语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

4.编译器指令重排

下面我们简单看一个编译器重排的例子：

线程 1 线程 2
1： x2 = a ; 3: x1 = b ;
2: b = 1; 4: a = 2 ;

两个线程同时执行，分别有1、2、3、4四段执行代码，其中1、2属于线程1 ， 3、4属于线程2 ，从程序的执行顺序上看，似乎不太可能出现x1 = 1 和x2 = 2 的情况，但实际上这种情况是有可能发现的，因为如果编译器对这段程序代码执行重排优化后，可能出现下列情况

线程 1 线程 2
2: b = 1; 4: a = 2 ;
1：x2 = a ; 3: x1 = b ;

这种执行顺序下就有可能出现x1 = 1 和x2 = 2 的情况，这也就说明在多线程环境下，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的。

5.指令集并行的重排序

指令集并行的重排序是对CPU的性能优化，从指令的执行角度来说一条指令可以分为多个步骤完成，如下:

• 取指 IF
• 译码和取寄存器操作数 ID
• 执行或者有效地址计算 EX
• 存储器访问 MEM
• 写回 WB

CPU在工作时，需要将上述指令分为多个步骤依次执行(注意硬件不同有可能不一样),由于每一个步会使用到不同的硬件操作，比如取指时会只有PC寄存器和存储器，译码时会执行到指令寄存器组，执行时会执行ALU(算术逻辑单元)、写回时使用到寄存器组。为了提高硬件利用率，CPU指令是按流水线技术来执行的，如下：

image

从图中可以看出当指令1还未执行完成时，第2条指令便利用空闲的硬件开始执行，这样做是有好处的，如果每个步骤花费1ms，那么如果第2条指令需要等待第1条指令执行完成后再执行的话，则需要等待5ms，但如果使用流水线技术的话，指令2只需等待1ms就可以开始执行了，这样就能大大提升CPU的执行性能。虽然流水线技术可以大大提升CPU的性能，但不幸的是一旦出现流水中断，所有硬件设备将会进入一轮停顿期，当再次弥补中断点可能需要几个周期，这样性能损失也会很大，就好比工厂组装手机的流水线，一旦某个零件组装中断，那么该零件往后的工人都有可能进入一轮或者几轮等待组装零件的过程。因此我们需要尽量阻止指令中断的情况，指令重排就是其中一种优化中断的手段，我们通过一个例子来阐明指令重排是如何阻止流水线技术中断的

a = b + c ;
d = e + f ;

下面通过汇编指令展示了上述代码在CPU执行的处理过程

image

• LW指令 表示 load，其中LW R1,b表示把b的值加载到寄存器R1中
• LW R2,c 表示把c的值加载到寄存器R2中
• ADD 指令表示加法，把R1 、R2的值相加，并存入R3寄存器中。
• SW 表示 store 即将 R3寄存器的值保持到变量a中
• LW R4,e 表示把e的值加载到寄存器R4中
• LW R5,f 表示把f的值加载到寄存器R5中
• SUB 指令表示减法，把R4 、R5的值相减，并存入R6寄存器中。
• SW d,R6 表示将R6寄存器的值保持到变量d中

上述便是汇编指令的执行过程，在某些指令上存在X的标志，X代表中断的含义，也就是只要有X的地方就会导致指令流水线技术停顿，同时也会影响后续指令的执行，可能需要经过1个或几个指令周期才可能恢复正常，那为什么停顿呢？这是因为部分数据还没准备好，如执行ADD指令时，需要使用到前面指令的数据R1，R2，而此时R2的MEM操作没有完成，即未拷贝到存储器中，这样加法计算就无法进行，必须等到MEM操作完成后才能执行，也就因此而停顿了，其他指令也是类似的情况。前面阐述过，停顿会造成CPU性能下降，因此我们应该想办法消除这些停顿，这时就需要使用到指令重排了，如下图，既然ADD指令需要等待，那我们就利用等待的时间做些别的事情，如把LW R4,e 和 LW R5,f 移动到前面执行，毕竟LW R4,e 和 LW R5,f执行并没有数据依赖关系，对他们有数据依赖关系的SUB R6,R5,R4指令在R4,R5加载完成后才执行的，没有影响，过程如下：

image

正如上图所示，所有的停顿都完美消除了，指令流水线也无需中断了，这样CPU的性能也能带来很好的提升，这就是处理器指令重排的作用。

6.内存系统的重排序

内存体系

image

图1.对于2012 Sandy Bridge核心来说，内存模型可以大致按照如下进行分解：

1.寄存器：在每个核心上，有160个用于整数和144个用于浮点的寄存器单元。访问这些寄存器只需要一个时钟周期，这构成了对执行核心来说最快的内存。编译器会将本地变量和函数参数分配到这些寄存器上。当使用超线程技术（ hyperthreading ）时，这些寄存器可以在超线程协同下共享。

2.内存排序缓冲（Memory Ordering Buffers (MOB)**** ）：MOB由一个64长度的load缓冲和36长度的store缓冲组成。这些缓冲用于记录等待缓存子系统时正在执行的操作。store缓冲是一个完全的相关性队列，可以用于搜索已经存在store操作，这些store操作在等待L1缓存的时候被队列化。在数据与缓存子系统传输时， 缓冲可以让处理器异步运转。当处理器异步读或者异步写的时候，结果可以乱序返回。为了使之与已发布的内存模型（ memory model ）一致，MOB用于消除load和store的顺序。

3.Level 1 缓存：L1是一个本地核心内的缓存，被分成独立的32K数据缓存和32K指令缓存。访问需要3个时钟周期，并且当指令被核心流水化时， 如果数据已经在L1缓存中的话，访问时间可以忽略。

4.L2缓存：L2缓存是一个本地核心内的缓存，被设计为L1缓存与共享的L3缓存之间的缓冲。L2缓存大小为256K，主要作用是作为L1和L3之间的高效内存访问队列。L2缓存同时包含数据和指令。L2缓存的延迟为12个时钟周期。

5.L3缓存： 在同插槽的所有核心都共享L3缓存。L3缓存被分为数个2MB的段，每一个段都连接到槽上的环形网络。每一个核心也连接到这个环形网络上。地址通过hash的方式映射到段上以达到更大的吞吐量。根据缓存大小，延迟有可能高达38个时钟周期。在环上每增加一个节点将消耗一个额外的时钟周期。缓存大小根据段的数量最大可以达到20MB。L3缓存包括了在同一个槽上的所有L1和L2缓存中的数据。这种设计消耗了空间，但是使L3缓存可以拦截对L1和L2缓存的请求，减轻了各核心私有的L1和L2缓存的负担。

6.主内存：在缓存完全没命中的情况下，DRAM通道到每个槽的延迟平均为65ns。具体延迟多少取决于很多因素，比如，下一次对同一缓存 行中数据的访问将极大降低延迟，而当队列化效果和内存刷新周期冲突时将显著增加延迟。每个槽使用4个内存通道聚合起来增加吞吐量，并通过在独立内存通道上流水线化（ pipelining ）将隐藏这种延迟。

7. ****NUMA：在一个多插槽的服务器上，会使用非一致性内存访问（ non-uniform memory access）。所谓的非一致性是指，需要访问的内存可能在另一个插槽上，并且通过 QPI 总线访问需要额外花费40ns。 Sandy Bridge对于以往的兼容系统来说，在2插槽系统上是一个巨大的进步。在 Sandy Bridge上，QPI总线的能力从6.4GT/s提升到8.0GT/s，并且可以使用两条线路，消除了以前系统的瓶颈。对于 Nehalem and Westmere 来说，QPI只能使用内存控制器为一个单独插槽分配的带宽中的40%，这使访问远程内存成为一个瓶颈。另外，现在QPI链接可以使用预读取请求，而前一代系统不行。

关联度（Associativity Levels）

缓存是一个依赖于hash表的高效硬件。使用hash函数常常只是将地址中低位bit 进行映射 ，以实现缓存索引。hash表需要有解决对于同一位置冲突的机制。 关联度就是hash表中槽（slot）的数量，也被称为组（ways）和集合（sets），可以用来存储一个内存地址的hash版本。关联度的多少需要在存储数据的容量，耗电量和查询时间之间寻找平衡。（校对注：关联度越高，槽的数量越多，hash冲突越小，查询速度越快）

对于Sandy Bridge，L1和L2是8路组相连 ，L3是12路组相连 。（For Sandy Bridge the L1D and L2 are 8-way associative, the L3 is 12-way associative.）

缓存一致性

由于一些缓存在内核本地，我们需要一些方法保证一致性，使所有核心的内存视图一致。对于主流系统来说，内存子系统需要考虑“真实的来源（source of truth）”。如果数据只从缓存中来，那么它永远不会过期；当数据同时在缓存和主内存中存在时，缓存中存的是主拷贝（master copy）。这种内存管理被称为写-回（write-back），在此方式下，当新的缓存行占用旧行，导致旧行被驱逐时，缓存数据只会被写回主内存中。x86架构的每个缓存块的大小为64 bytes，称为缓存行（ cache-line）。其它种类的处理器的缓存行大小可能不同。更大的缓存行容量降低延迟，但是需要更大的带宽（校对注：数据总线带宽）。

对于不同插槽的CPU，L1和L2的数据并不共享，一般通过MESI协议保证Cache的一致性，但需要付出代价。

在MESI协议中，每个Cache line有4种状态，分别是：

1、M(Modified)这行数据有效，但是被修改了，和内存中的数据不一致，数据只存在于本Cache中

2、E(Exclusive)这行数据有效，和内存中的数据一致，数据只存在于本Cache中

3、S(Shared)这行数据有效，和内存中的数据一致，数据分布在很多Cache中

4、I(Invalid)这行数据无效

每个Core的Cache控制器不仅知道自己的读写操作，也监听其它Cache的读写操作，假如有4个Core：1、Core1从内存中加载了变量X，值为10，这时Core1中缓存变量X的cache line的状态是E；2、Core2也从内存中加载了变量X，这时Core1和Core2缓存变量X的cache line状态转化成S；3、Core3也从内存中加载了变量X，然后把X设置成了20，这时Core3中缓存变量X的cache line状态转化成M，其它Core对应的cache line变成I（无效）

当然了，不同的处理器内部细节也是不一样的，比如Intel的core i7处理器使用从MESI中演化出的MESIF协议，F(Forward)从Share中演化而来，一个cache line如果是F状态，可以把数据直接传给其它内核，这里就不纠结了。

CPU在cache line状态的转化期间是阻塞的，经过长时间的优化，在寄存器和L1缓存之间添加了LoadBuffer、StoreBuffer来降低阻塞时间，LoadBuffer、StoreBuffer，合称排序缓冲(Memoryordering Buffers (MOB))，Load缓冲64长度，store缓冲36长度，Buffer与L1进行数据传输时，CPU无须等待。

1、CPU执行load读数据时，把读请求放到LoadBuffer，这样就不用等待其它CPU响应，先进行下面操作，稍后再处理这个读请求的结果。2、CPU执行store写数据时，把数据写到StoreBuffer中，待到某个适合的时间点，把StoreBuffer的数据刷到主存中。

因为StoreBuffer的存在，CPU在写数据时，真实数据并不会立即表现到内存中，所以对于其它CPU是不可见的；同样的道理，LoadBuffer中的请求也无法拿到其它CPU设置的最新数据；

由于StoreBuffer和LoadBuffer是异步执行的，所以在外面看来，先写后读，还是先读后写，没有严格的固定顺序。

TBD1.png

TBD2.png

TBD3.png

MESI协议中有两个行为效率会比较低，

1. 当cache line状态为Invalid时，需要写入数据。
2. 把cache line的状态变为invalid

CPU通过store buffer和invalid queue(用来实现LoadBuffer)来降低延时。
当在invalid状态进行写入时，首先会给其它CPU核发送invalid消息，然后把当前写入的数据写入到store buffer中。然后在某个时刻在真正的写入到cache line中。由于不是马上写入到cache line中，所以当前核如果要读cache line中的数据，需要先扫描store buffer，同时其它CPU核是看不到当前核store buffer中的数据的。除非store buffer中的数据被刷到cache中。
对于invalid queue，当收到invalid消息时，cache line不会马上变成invalid状态，而是把消息写入invalid queue中。和store buffer不同的是当前核是无法扫描invalid queue的。
为了保证数据的一致性，这就需要memory barrier了。store barrier会把store buffer中的数据刷到cache中，read barrier会执行invalid queue中的消息。

注意
要保证数据的一致性，仅仅有MESI协议还不够，通常还需要memory barrier的配合。

7.memory barrier

memory barrier的作用有两个

• 保证数据的可见性
  我们知道，内存中的数据除了在内存中的副本，还有可能在各个核的CPU中，当某个核修改了对应cache中的数据后，这时其它核中对应内存地址的数据还有主存中的数据就不是最新的了，其它核为了能够读取到最新的数据，需要执行memory barrier指令，把store buffer中的修改写到主存中。
• 防止指令之间的重排序
  前面讲到一条指令的执行会分为几个步骤，也就是pipeline，为了得到更高的性能，编译器或者处理器有可能会改变指令的执行顺序，以此来提高指令执行的并行度。不管是编译器还是处理器的重排序，都要遵守as-if-serial语义。as-if-serial说的是，不管怎么重排序，在单线程中执行这些指令，其结果应该是一样的。在多线程的情况下，需要memory barrier来保证整体的顺序，否则会出现意想不到的结果。

不同的处理器架构的memory barrier也不太一样，以Intel x86为例，有三种memory barrier

TBD4.png

store barrier

对应sfence指令

1. 保证了sfence前后store指令的顺序，防止重排序。
2. 通过刷新store buffer保证了sfence之后的store指令全局可见之前，sfence之前的store要指令要先全局可见。

load barrier

对应lfence指令，

1. 保证了lfence前后的load指令的顺序，防止重排序。
2. 刷新load buffer。

full barrier

对应mfence指令

1. 保证了mfence前后的store和load指令的顺序，防止重排序。
2. 保证了mfence之后的store指令全局可见之前，mfence之前的store指令要先全局可见。

TBD5.png

TBD6.png

8. JDK 1.7 内存屏障实现

JVM的代码。

1.png

执行完赋值操作后，紧接着执行OrderAccess::storeload()，这又是啥？

其实这就是经常会念叨的内存屏障，之前只知道念，却不知道是如何实现的。从CPU缓存结构分析中已经知道：一个load操作需要进入LoadBuffer，然后再去内存加载；一个store操作需要进入StoreBuffer，然后再写入缓存，这两个操作都是异步的，会导致不正确的指令重排序，所以在JVM中定义了一系列的内存屏障来指定指令的执行顺序。

JVM中定义的内存屏障如下，JDK1.7的实现

2.png

下面是常见处理器允许的重排序类型的列表：

11.png

上表单元格中的 “N” 表示处理器不允许两个操作重排序，“Y” 表示允许重排序。

从上表我们可以看出：常见的处理器都允许 Store-Load 重排序；常见的处理器都不允许对存在数据依赖的操作做重排序。sparc-TSO 和 x86 拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。

12.png

Store Barrier
sfence指令实现了Store Barrier，相当于StoreStore Barriers。
强制所有在sfence指令之前的store指令，都在该sfence指令执行之前被执行，发送缓存失效信号，并把store buffer中的数据刷出到CPU的L1 Cache中；所有在sfence指令之后的store指令，都在该sfence指令执行之后被执行。即，禁止对sfence指令前后store指令的重排序跨越sfence指令，使所有Store Barrier之前发生的内存更新都是可见的。
这里的“可见”，指修改值可见（内存可见性）且操作结果可见（禁用重排序）。下同。

内存屏障的标准中，讨论的是缓存与内存间的相干性，实际上，同样适用于寄存器与缓存、甚至寄存器与内存间等多级缓存之间。x86架构使用了MESI协议的一个变种，由协议保证三层缓存与内存间的相关性，则内存屏障只需要保证store buffer（可以认为是寄存器与L1 Cache间的一层缓存）与L1 Cache间的相干性。下同。

Load Barrier
lfence指令实现了Load Barrier，相当于LoadLoad Barriers。
强制所有在lfence指令之后的load指令，都在该lfence指令执行之后被执行，并且一直等到load buffer被该CPU读完才能执行之后的load指令（发现缓存失效后发起的刷入）。即，禁止对lfence指令前后load指令的重排序跨越lfence指令，配合Store Barrier，使所有Store Barrier之前发生的内存更新，对Load Barrier之后的load操作都是可见的。

Full Barrier
mfence指令实现了Full Barrier，相当于StoreLoad Barriers。
mfence指令综合了sfence指令与lfence指令的作用，强制所有在mfence指令之前的store/load指令，都在该mfence指令执行之前被执行；所有在mfence指令之后的store/load指令，都在该mfence指令执行之后被执行。即，禁止对mfence指令前后store/load指令的重排序跨越mfence指令，使所有Full Barrier之前发生的操作，对所有Full Barrier之后的操作都是可见的。

1、loadload屏障（load1，loadload， load2）2、loadstore屏障（load，loadstore， store）

这两个屏障都通过acquire()方法实现

3.png

其中__asm__，表示汇编代码的开始。volatile，之前分析过了，禁止编译器对代码进行优化。.最后的"memory"是编译器屏障的作用。

在LoadBuffer中插入该屏障，清空屏障之前的load操作，然后才能执行屏障之后的操作，可以保证load操作的数据在下个store指令之前准备好

3、storestore屏障（store1，storestore， store2）通过"release()"方法实现：

4.png

在StoreBuffer中插入该屏障，清空屏障之前的store操作，然后才能执行屏障之后的store操作，保证store1写入的数据在执行store2时对其它CPU可见。

4、storeload屏障（store，storeload， load）对java中的volatile变量进行赋值之后，插入的就是这个屏障，通过"fence()"方法实现：

5.png

看到这个有没有很兴奋？

通过os::is_MP()先判断是不是多核，如果只有一个CPU的话，就不存在这些问题了。

storeload屏障，完全由下面这些指令实现

__asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");

为了试验这些指令到底有什么用，我们再写点c++代码编译一下

#include <iostream>

int foo = 10;

int main(int argc, const char * argv[]) {
    // insert code here...
    volatile int a = foo + 10;
    // __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
    volatile int b = foo + 20;

    return 0;
}

为了变量a和b不被编译器优化掉，这里使用了volatile进行修饰，编译后的汇编指令如下：

9.png

从编译后的代码可以发现，第二次使用foo变量时，没有从内存重新加载，使用了寄存器的值。

把__asm__ volatile ***指令加上之后重新编译

10.png

相比之前，这里多了两个指令，一个lock，一个addl。lock指令的作用是：在执行lock后面指令时，会设置处理器的LOCK#信号（这个信号会锁定总线，阻止其它CPU通过总线访问内存，直到这些指令执行结束），这条指令的执行变成原子操作，之前的读写请求都不能越过lock指令进行重排，相当于一个内存屏障。

还有一个：第二次使用foo变量时，从内存中重新加载，保证可以拿到foo变量的最新值，这是由如下指令实现

__asm__ volatile ( : : : "cc", "memory");

同样是编译器屏障，通知编译器重新生成加载指令(不可以从缓存寄存器中取)。

读取volatile变量

同样在bytecodeInterpreter.cpp文件中，找到getstatic字节码指令的解释器实现。

7.png

通过obj->obj_field_acquire(field_offset)获取变量值

8.png

最终通过OrderAccess::load_acquire实现

inline jint OrderAccess::load_acquire(volatile jint* p) { return *p; }

底层基于C++的volatile实现，因为volatile自带了编译器屏障的功能，总能拿到内存中的最新值。