JMM(Java Memory Model),乱序执行和指令重排

存储器层次结构

Cache line的概念,缓存行对齐,伪共享

多线程一致性的硬件层支持

MESI Cache一致性协议(重点)

现代CPU的数据一致性实现 = 缓存锁(MESI ...) + 总线锁

读取缓存以cache line为基本单位,目前64bytes

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

伪共享问题:JUC/c028FalseSharing

使用缓存行的对齐能够提高效率

Disrupter

使用了缓存行对齐

乱序问题

保证有序

volatile 关键字

加锁可以保证一致性,但是效率不够高

内存屏障

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

硬件内存屏障 X86

  • sfence: store| 在sfence指令前的写操作当必须在sfence指令后的写操作前完成。
  • lfence:load | 在lfence指令前的读操作当必须在lfence指令后的读操作前完成。
  • mfence:modify/mix | 在mfence指令前的读写操作当必须在mfence指令后的读写操作前完成。
  • 原子指令,如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的实现细节

字节码层面:ACC_VOLATILE:这是一个标志位

JVM 层面,volatile内存区的读写:都加屏障

  • StoreStoreBarrier
  • volatile 写操作
  • StoreLoadBarrier
  • LoadLoadBarrier
  • volatile 读操作
  • LoadStoreBarrier

OS和硬件层面,hsdis - HotSpot Dis Assembler windows lock 指令实现 | MESI实现

文章地址:https://blog.csdn.net/qq_26222859/article/details/52235930

synchronized实现细节

  1. 字节码层面 ACC_SYNCHRONIZED monitorenter monitorexit
  2. JVM层面 C C++ 调用了操作系统提供的同步机制
  3. OS和硬件层面 X86 : lock cmpxchg / xxx 

文章地址:https://blog.csdn.net/21aspnet/article/details/88571740

java并发内存模型

JVM规定的重排序规则

JLS17.4.5

无论如何排序,单线程执行结果不变

论读书
睁开眼,书在面前
闭上眼,书在心里
原文地址:https://www.cnblogs.com/YC-L/p/14410347.html