介绍
volatile主要两个特性，可见性和有序性。
- 可见性是使用lock前缀实现，lock前缀可实现嗅探机制，每个处理器都会有一个嗅探机制，去看自己的工作内存中的数值与主内存中那个的是否一致，不一致，会将自己的工作内存中的数值设置成无效，同时会从主内存中读取数值更新到自己的工作内存中。
- 有序性是通过内存屏障，禁止指令重排，内存屏障还可以强制刷出各种CPU的缓存数据保证可见性
volatile特性
把对volatile变量的单个读、写，看出是使用同一个锁对这些单个读、写做了同步，比如：
public class VolatileFeaturesExample {
volatile long vl = 0L;
public void set(long l) {
vl = l;
}
public void getAndIncrement() {
vl++;// 复合（多个）volatile变量的读/写
}
public long get() {
return vl;// 单个volatile变量的读
}
}等价于
class VolatileFeaturesExample1 {
long vl = 0L;
public synchronized void set(long l) {
vl = l;
}
public synchronized long get() {
return vl;
}
public void getAndIncrement() {
long temp = get();
temp += 1L;
set(temp);
}
}因为锁happens-before规则保证释放锁和获取锁两个线程之间的内存可见性，由可以推出，volatile变量的读总能看到对这个volatile变量最后的写入，而锁也决定了临界区代码的执行具有原子性，也就说，volatile变量同样对读写具有原子性
由上得出，volatile变量具有下列特性：
- 可见性，volatile变量的读总能看到对这个volatile变量最后的写入
- 原子性，对任意单个volatile变量的读写具有原子性，但volatile++复合操作是不具有原子性的
volatile写/读建立的happens before关系
从内存的角度来说，volatile的写-读与锁的释放-获取有相同的内存效果
public class VolatileExample {
int a=0;
volatile boolean flag=false;
public void writer(){
a=1; //1
flag=true;//2
}
public void reader(){
if(flag){//3
int i=a;//4
}
}
}- 根据程序次序规则，1 happens before 2，3 happens before 4
- 根据volatile规则，2 happens before 3
- 根据happens before的传递规则，1 happens before 4
（1）当执行写入volatile时，也就是2，JMM会将该线程A对应本地内存更新过的共享变量刷新到主内存，那到共享变量a对其他线程是可见的，也就读到a就是想要的1，而不是0
（2）当读一个volatile变量时，JMM会把该线程B对应的本地内存置为无效，线程直接从主内存读取共享变量，同时该读操作会把本地内存的值更为与主内存的值统一
volatile内存语义的实现
下面看看JMM如何实现volatile写/读的内存语义
重排序分为编译器重排序和处理器重排序，JMM会限制这两种类型的重排序类型来保证volatile的内存语义
- 第二个操作是volatile写时，第一个操作不管是什么，都不能重排序
- 第一个操作是volatile读时，第二个操作不管是什么，都不能重排序
- 第一个操作是volatile是写，第二个操作是volatile是读，不能重排序
JMM内存屏障插入策略：（Load：加载（读）、Store：保存（写），屏障名称就可以看出读写的先后顺序）
- 在每个volatile写操作前插入StroreStore屏障
- 在每个volatile写操作前插入StroreLoad屏障
- 在每个volatile读操作前插入LoadLoad屏障
- 在每个volatile读操作前插入LoadStore屏障
volatile写操作
上面的StroreStore屏障保证了在volatile写之前，其前面的所有普通写操作对任意处理器都是可见的，因为StroreStore屏障保障所有的普通写在本地内存的数据在voltile写之前刷新到主内存
- 而volatile写后面的StoreLoad屏障，作用是避免
- volatile写与后面可能有的volatile读/写操作重排序
volatile读操作
下面为代码示例
public class VolatileBarrierExample {
int a;
volatile int v1 = 1;
volatile int v2 = 2;
void readAndWrite() {
int i = v1;// 第一个volatile读
int j = v2;// 第二个volatile读
a = i + j;// 普通写
v1 = i + 1;// 第一个volatile写
v2 = j * 2;// 第二个volatile写
}
}编译器生成字节码过程
最后的StoreLoad屏障不能省略，因为编译器无法确定第二个volatile写后是否会有volatile读或写，保守起见，都会在该处加一个StoreLoad屏障
JVM中定义的内存屏障如下，JDK1.7的实现
- loadload屏障（load1，loadload， load2）
- loadstore屏障（load，loadstore， store）
这两个屏障都通过acquire()方法实现
volatile和CAS底层实现都用CPU的lock指令，他们有什么不同？
首先lock只是前缀，lock后面一定有跟命令，具体看后面的命令
- volatile没有保证原子性，volatile的实现需要内存屏障，由于lock前缀的指令具有内存屏障的效果，这里的lock addl $0x0,(%rsp)是用来作内存屏障使用的。
storeload屏障，完全由下面这些指令实现
__asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");这里多了两个指令，一个lock，一个addl。
lock指令的作用是：在执行lock后面指令时，会设置处理器的LOCK#信号（这个信号会锁定总线，阻止其它CPU通过总线访问内存，直到这些指令执行结束），这条指令的执行变成原子操作，之前的读写请求都不能越过lock指令进行重排，相当于一个内存屏障。
- CAS保证原子性，CAS的实现用了lock cmpxchg指令。cmpxchg指令涉及一次内存读和一次内存写，需要lock前缀保证中间不会有其它cpu写这段内存。
- lock只是前缀。cas 指定了lock后面的指令必须是交换，volatile lock后面的指令要看编译时的实际情况。
- CAS给cmpxchg指令加lock前缀，是为了cmpxchg指令在多核处理器情况能保证原子性
lock前缀的具体作用
Lock指令区分两种实现方法
- 早期 – Pentium时代（锁总线），在Pentium及之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其它处理器暂时无法通过总线访问内存，很显然，这个开销很大。
- 现在 – P6以后时代（锁缓存），在新的处理器中，Intel使用缓存锁定来保证指令执行的原子性，缓存锁定将大大降低lock前缀指令的执行开销。
这里锁缓存（Cache Locking）就是用了Ringbus + MESI协议。
MESI大致的意思是：若干个CPU核心通过ringbus连到一起。每个核心都维护自己的Cache的状态。如果对于同一份内存数据在多个核里都有cache，则状态都为S（shared）。
一旦有一核心改了这个数据（状态变成了M），其他核心就能瞬间通过ringbus感知到这个修改，从而把自己的cache状态变成I（Invalid），并且从标记为M的cache中读过来。同时，这个数据会被原子的写回到主存。最终，cache的状态又会变为S。
这相当于给cache本身单独做了一套总线（要不怎么叫ring bus），避免了真的锁总线。
我们可以发现MESIF协议大大降低了读操作的时延,没有让写操作更慢，同时保持了一致性。
但是在多核情况下，就不是这么简单的了。每个cpu都有自己的缓存，每个cpu最终看到的数据，就是不在缓存中的主存+已在缓存中的数据。所以假设多cpu的情况下，某个cpu更新了某个cache line中的值又没有回写到内存中，那么其它cpu中的数据其实已经是旧的已作废的数据，这是不可接受的。
为了解决这种情况，引入了缓存一致性协议，其中用的比较多的称为MESI，分别是cache line可能存在的四种状态：
- Modified。 数据已读入cache line，并且已经被修改过了。该cpu拥有最新的数据，可以直接修改数据。当其它核心需要读取相应数据的时候，此数据必须刷入主存。
- Exclusive。 数据已读入cache line，并且只有该cpu拥有它。该cpu可以直接修改数据，但是该数据与主存中数据是一致的。
- Shared。 多个cpu共享某内存的数据，可能由Exclusive状态改变而来，当某个cpu需要修改数据的时候，必须提交RFO请求来获取数据的独占权，然后才能进行修改。
- Invalid。 无效的cache line，和没有载入一样。当某个cpu的cache line处于- – Shared状态，别的cpu申请写的时候，接收了RFO请求后会变为此种状态。
这四种状态可以不断的改变，有了这套协议，不同的cpu之间的缓存就可以保证数据的一致性了。但是依赖这套协议，会大大的降低性能，比如一个核心上某个Shared的cache line打算写，则必须先RFO来获取独占权，当其它核心确认了之后才能转为Exclusive状态来进行修改，假设其余的核心正在处理别的事情而导致一段时间后才回应，则会当申请RFO的核心处于无事可做的状态，这是不可接受的。
于是在每个cpu中，又加入了两个类似于缓存的东西，分别称为Store buffer与Invalidate queue。
Store buffer用于缓存写指令，当cpu需要写cache line的时候，并不会执行上述的流程，而是将写指令丢入Store buffer，当收到其它核心的RFO回应后，该指令才会真正执行。
Invalidate queue用于缓存Shared->Invalid状态的指令，当cpu收到其它核心的RFO指令后，会将自身对应的cache line无效化，但是当核心比较忙的时候，无法立刻处理，所以引入Invalidate queue，当收到RFO指令后，立刻回应，将无效化的指令投入Invalidate queue。
这套机制大大提升了性能，但是很多操作其实也就异步化了，某个cpu写入了东西，则该写入可能只对当前CPU可见（读缓存机制会先读Store buffer，再读缓存），而其余的cpu可能无法感知到内存发生了改变，即使Invalidate queue中已有该无效化指令。
为了解决这个问题，引入了读写屏障。写屏障主要保证在写屏障之前的在Store buffer中的指令都真正的写入了缓存，读屏障主要保证了在读屏障之前所有Invalidate queue中所有的无效化指令都执行。有了读写屏障的配合，那么在不同的核心上，缓存可以得到强同步。
所以在锁的实现上，一般lock都会加入读屏障，保证后续代码可以读到别的cpu核心上的未回写的缓存数据，而unlock都会加入写屏障，将所有的未回写的缓存进行回写。
参考《深入理解Java内存模型》
来源：blog.csdn.net/jyxmust/article/details/76946283
作者：在云端123
