Jvm03-Java Memory Model （内存模型）

1、硬件层的并发优化基础知识

硬件层面需要解决，当我们的数据分配的不同的CPU后数据的一致性问题

解决1: 总线锁
	- 效率低，一个CPU去总线访问X，被上了锁，另一个CPU去访问Y也需要等待，因为把整个总线进行了上锁。

英特尔采用 MESI 一致性协议 称为缓存锁
给每一个缓存的内容做了一个标记
	- CPU读取到一个数进来，和主存相比如果发生修改，标记为Modified
	- 如果这个数被我独有，标记为Exclusive
	- 如果我读的时候，你也在读，标记为Shared
	- 如果我读的时候，被别的CPU改过，（读进来的时候是2，被其他CPU修改为3了）标记为Invalid
	通过四种状态，来进行处理
但是MESI并没有完全解决锁总线的问题，现在的CPU依然需要总线锁。
	比如有些数据比较大，无法缓存。必须使用总线锁。
现代CPU的数据一致性的实现 = 缓存锁(MESI...等协议) + 总线锁

什么是cache line?
	读取缓存，以cache line 为基本单位，目前多数为64Byte
缓存行的伪共享?
	位于同一缓存行的不同数据，被不同CPU锁定，产生相互影响的伪共享问题。
	若一个CPU修改了X，另一个CPU会将整个缓存行设置为Invalid,通知其他CPU更新整个

缓存航如何提高效率?
	- 使用缓存行对齐。8 * 8 = 64Byte
	- 号称效率最高的队列，disruptor 保证无论如何我的cursor指针不管跟前面对齐还是跟后面对齐，都不会和其他数据混在同一个缓存行

2、乱序问题

CPU为了提高指令执行效率，会在一条指令执行过程中，去同时执行另一条指令，前提是，两条指令没有依赖关系。

3、如何保证特定情况下不乱序

硬件级别如何保证

Jvm级别如何保证

volatile 实现细节
	字节码层面: 
		Access_flag 加了一个访问符Volatile
	Jvm层面:
		Volatile在读写操作前后都加了一个内存屏障
		StoreStoreBarrier
		Volatile 写操作
		StoreLoadBarrier
	--------------------------
		LoadLoadBarrier
		Volatile
		LoadStoreBarrier
synchronized 实现细节
	字节码层面:
		同步方法	Access_flag 加了一个访问符Synchronized
		同步代码块	Monitorenter Monitorexit
	Jvm层面:
		C++调用了操作系统的同步机制