再来看看release_int_field_put方法

内部的赋值动作被包了一层，OrderAccess::release_store究竟做了魔法，可以让其它线程读到变量i的最新值。

奇怪，在OrderAccess::release_store的实现中，第一个参数强制加了一个volatile，很明显，这是c/c++的关键字。

c/c++中的volatile关键字，用来修饰变量，通常用于语言级别的 memory barrier，在”The C++ Programming Language”中，对volatile的描述如下：

A volatile specifier is a hint to a compiler that an object may change its value in ways not specified by the language so that aggressive optimizations must be avoided.

volatile是一种类型修饰符，被volatile声明的变量表示随时可能发生变化，每次使用时，都必须从变量i对应的内存地址读取，编译器对操作该变量的代码不再进行优化，下面写两段简单的c/c++代码验证一下

#include <iostream>

int foo = 10;
int a = 1;
int main(int argc, const char * argv[]) {
    // insert code here...
    a = 2;
    a = foo + 10;
    int b = a + 20;
    return b;
}

代码中的变量i其实是无效的，执行g++ -S -O2 main.cpp得到编译之后的汇编代码如下：

可以发现，在生成的汇编代码中，对变量a的一些无效负责操作果然都被优化掉了，如果在声明变量a时加上volatile

#include <iostream>

int foo = 10;
volatile int a = 1;
int main(int argc, const char * argv[]) {
    // insert code here...
    a = 2;
    a = foo + 10;
    int b = a + 20;
    return b;
}

再次生成汇编代码如下：

和第一次比较，有以下不同：

1、对变量a赋值2的语句，也保留了下来，虽然是无效的动作，所以volatile关键字可以禁止指令优化，其实这里发挥了编译器屏障的作用；

编译器屏障可以避免编译器优化带来的内存乱序访问的问题，也可以手动在代码中插入编译器屏障，比如下面的代码和加volatile关键字之后的效果是一样

#include <iostream>

int foo = 10;
int a = 1;
int main(int argc, const char * argv[]) {
    // insert code here...
    a = 2;
    __asm__ volatile ("" : : : "memory"); //编译器屏障
    a = foo + 10;
    __asm__ volatile ("" : : : "memory");
    int b = a + 20;
    return b;
}

编译之后，和上面类似

2、其中_a(%rip)是变量a的每次地址，通过movl $2, _a(%rip)可以把变量a所在的内存设置成2，关于RIP，可以查看 x64下PIC的新寻址方式：RIP相对寻址

所以，每次对变量a的赋值，都会写入到内存中；每次对变量的读取，都会从内存中重新加载。

感觉有点跑偏了，让我们回到JVM的代码中来。

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

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

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

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

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

其中__asm__，表示汇编代码的开始。
volatile，之前分析过了，禁止编译器对代码进行优化。
把这段指令编译之后，发现没有看懂….最后的”memory”是编译器屏障的作用。

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

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

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

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

看到这个有没有很兴奋？

通过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进行修饰，编译后的汇编指令如下：

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

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