volatile关键字的学习

关于volatile的理解

Java语言可以访问共享变量，为了确保共享变量能被准确一致的更新，java提供了volatile关键字，保证volatile变量之前任意操作，不会被重排序到volatile写之后，保证volatile读之后的所有操作不会不会被重排序到volatile读之前，同时volatile写会把所有的cpu缓存刷新到主内存中，volatile读及之后的操作读取共享变量必须从主存中重新读取最新的数据。
通过这一系列的操作，保证了volatile写之前的所有对共享变量操作，对后续的volatile读及之后所有操作都是可见的。

顺序一致性模型

顺序一致性模型，是java多线程运行的理想模型，线程内部按照代码编写的顺序严格执行，多个线程串行执行，上一个线程的执行结果，对下一个线程可见

synchorized

同步锁的实现，可以保证最终结果和顺序一致性模型保持一致，多个同步代码块之间串行执行，但是同步代码块内部如果数据不存在依赖关系编译期和处理器会进行适当重排序，提升程序性能。

valotile仅仅支持单个元素原子操作的可见性，有序性，对于非原子性操作，volatile不能像同步锁，保证程序遵循顺序一致性模型的执行结果

volatile int i=0;
Thread{
	run(){
		i++;
	}
}

上述伪代码，i++可以分解为三步:

• volatile读
• 普通运算
• volatile写
  依靠volatile无法保证这三个操作按照线程串行执行
  

volatile产生的背景

CPU层面多线程通信

为了提升程序的性能，多个CPU之间会存在CPU高速缓存，多个线程分别在多个CPU上执行，如果有共享数据，会将主内存中的数据备份一份到CPU高速缓存中。但是这也带来了数据可见性问题。
CPU层面提供了两种解决方案:总线锁和缓存锁

总线锁

总线锁是一种效率较低但是简单处理可见性问题的方式，当某一个CPU对共享变量进行操作时，其他CPU和内存之间的通信就会被锁住。我们只要保证当前操作的共享数据是原子操作就行了，但是总线锁定期间其他处理器不能操作其他内存地址的数据，因此诞生了缓存锁。

缓存锁

缓存锁的实现依赖于缓存一致性协议，比较典型就是： MESI协议

MESI协议

以缓存行为单位，如果一个数据跨缓存行将会退化到总线锁。该协议要求在每个缓存行上维护两个状态位，使得每个数据单位可能处于M、E、S和I这四种状态之一，各种状态含义如下：

• M(Modified): 数据被修改，并且数据只存在当前CPU中，其他CPU中没有。相对于主内存来说数据已经修改，还没有更新到主内存中
• E(Exclusive): 独占的，数据只在当前CPU中，并且数据和主内存中一致
• S(Share): 共享的。数据存在多个CPU中，并且数据和主内存中一致
• I(Invalid): 无效的。 本CPU中缓存的值标识为无效
  **CPU读请求：**缓存处于 M、E、S 状态都可以被读取，I 状态CPU 只能从主存中读取数据
  **CPU写请求：**缓存处于 M、E 状态才可以被写。对于S状态的写，需要将其他CPU中缓存行置为无效才行。

MESI带来的问题

如果一个Share状态的数据，在CPU0中被更改，它的状态变为Modified，并且需要通知其他CPU标识该数据状态为Invalid，在收到回执ACK期间，CPU0处于阻塞状态。

为了不让CPU0阻塞，在CPU中又引入了store buffers。在CPU0中，我们将修改的数据首先存入store buffers中而不是直接操作缓存行，然后CPU0继续向下执行，同时异步发送invalid消息到其他CPU，在收到回执ACk之后再写入缓存行，再同步到主内存中。但是这将会到导致可见行的问题，CPU0的数据修改，其他CPU不能及时拿到最新的数据。

//伪代码
Demo{
	int i=0;
	boolean flag=false;
	Thread threadA = new Thread(() -> {
		i=100; //S状态
		flag=true; //E状态
	});
	Thread threadB = new Thread()() -> {
		if(flag){
			System.out.println(i == 100);
		}
	};
	threadA.start();
	threadB.start();
}

线程A运行i=100；由于 i 的状态为S，写入store buffers中，异步执行通知其他CPU，继续执行flag=true，flag为E状态，直接写入主内存不需要通知其他CPU
B线程从主内存读取flag=true，此时store buffers的数据可能没有及时同步状态到其他CPU，B中可能任然是初始i=0,最终打印结果为flase。
为了保证结果正确，就必须要在A中的flag写入之前将 i=100；写入到主内存，并且其他线程需要重新从主存中获取数据。

内存屏障

写屏障(Store Memory Barrier):告诉处理器在写屏障之前所有已经存储在store buffers中的数据，同步到主内存。
读屏障(Load Memory Barrier): 处理器在读屏障之后的所有读操作，必须在读屏障之后执行。配合写屏障，是的写屏障之前的所有堆内存的修改，对读屏障之后的操作可见。
全屏障(Full Memory Barrier): 确保屏障前的内存读写操作的结果提交到内存后，在执行屏障后的读写
CPU通过内存屏障机制，限制指令重排序解决处理器重排序带来的可见性问题。

```java
//伪代码
Demo{
	int i=0;
	boolean flag=false;
	Thread threadA = new Thread(() -> {
		i=100; //S状态
		storeBarrier();//插入写屏障 使得i=100直接写入主存
		flag=true; //E状态
	});
	Thread threadB = new Thread()() -> {
		if(flag){
			storeBarrier();//插入读屏障，使得i需要从主存中获取最新数据
			System.out.println(i == 100);
		}
	};
	threadA.start();
	threadB.start();
}

Java的JMM内存模型

JVM层面提供了一种抽象的内存模型(JMM)来兼容各种不同硬件的实现。

JMM层面的内存屏障

在JMM 中把内存屏障分为四类：

StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他3个屏障的效果。现代的多数处理器大多支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（Buffer Fully Flush）。

总结

并发编程中有三大特性：原子性、可见性、有序性，volatile通过内存屏障禁止指令重排序，主要遵循以下三个规则：

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。
为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略：

• 在每个volatile写操作的前面插入一个StoreStore屏障。
• 在每个volatile写操作的后面插入一个StoreLoad屏障。
• 在每个volatile读操作的后面插入一个LoadLoad屏障。
• 在每个volatile读操作的后面插入一个LoadStore屏障。