JMM--JAVA内存模型

硬件层数据一致性

Intel用MESI Cache一致性协议（为了使各个CPU之间的缓存保持一致性）

现代CPU的一致性是通过 缓存锁（MESI...）+总线锁 实现

缓存行、伪共享

读取缓存以cache line为基本单位（一块内存），目前64bytes

位于同一缓存行的两个不同数据，被两个不同CPU锁定，产生互相影响的伪共享问题

伪共享问题：JUC/c_028_FalseSharing

使用缓存行的对齐（占用满64bytes）能够提高效率

乱序问题

CPU为了提高指令执行效率，会在一条指令执行过程中（比如去内存读数据（慢100倍）），去同时执行另一条指令，前提是，两条指令没有依赖关系

CPU合并写操作

CPU中有一个4个字节的超高速缓存，刚好4字节填满之后进行合并写 这样效率更高

https://www.cnblogs.com/liushaodong/p/4777308.html

JUC/029_WriteCombining

乱序执行的证明：JVM/jmm/Disorder.java

原始参考：Memory Reordering Caught in the Act

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

硬件内存屏障 X86

sfence:  store| 在sfence指令前的写操作当必须在sfence指令后的写操作前完成。
lfence：load | 读操作
(全能屏障)mfence：modify/mix | 读写操作

原子指令，如x86上的”lock …” 指令是一个Full Barrier，执行时会锁住内存子系统来确保执行顺序，甚至跨多个CPU。Software Locks通常使用了内存屏障或原子指令来实现变量可见性和保持程序顺序

JVM级别如何规范（JSR133）

LoadLoad屏障：
对于这样的语句Load1; LoadLoad; Load2，

在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：

对于这样的语句Store1; StoreStore; Store2，

在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：

对于这样的语句Load1; LoadStore; Store2，

在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障(全能屏障)：
对于这样的语句Store1; StoreLoad; Load2，

在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。

volatile的实现细节

1. 字节码层面
   ACC_VOLATILE

1. JVM层面
   volatile内存区的读写 前后都加屏障

StoreStoreBarrier

volatile 写操作

StoreLoadBarrier

LoadLoadBarrier

volatile 读操作

LoadStoreBarrier

1. OS和硬件层面
   volatile与lock前缀指令_zhifeng687的博客-CSDN博客
   hsdis - HotSpot Dis Assembler
   windows lock 指令实现 | MESI实现

synchronized实现细节

1. 字节码层面
   ACC_SYNCHRONIZED
   monitorenter、monitorexit指令实现
2. JVM层面
   C C++ 调用了操作系统提供的同步机制
3. OS和硬件层面：通过处理器的lock指令实现

X86 : lock 指令实现
https://blog.csdn.net/21aspnet/article/details/88571740

趋势 优化过的synchronized效率也高 所以用synchronized代替volatile的趋势