>原文链接:https://www.jianshu.com/p/2ab5e3d7e510
# 为什么会有内存屏障
每个 CPU 都会有自己的缓存(有的甚至L1,L2,L3),缓存的目的就是为了提高性能,避免每次都要向内存取。但是这样的弊端也很明显:不能实时的和内存发生信息交换,分在不同 CPU 执行的不同线程对同一个变量的缓存值不同。
用 volatile 关键字修饰变量可以解决上述问题,那么 volatile 是如何做到这一点的呢?那就是内存屏障,内存屏障是硬件层的概念,不同的硬件平台实现内存屏障的手段并不是一样,java 通过屏蔽这些差异,统一由 jvm 来生成内存屏障的指令。
# 内存屏障是什么
硬件层的内存屏障分为两种:`Load Barrier` 和 `Store Barrier` 即读屏障和写屏障。
内存屏障有两个作用:
- 阻止屏障两侧的指令重排序;
- 强制把写缓冲区/高速缓存中的脏数据等写回主内存,让缓存中相应的数据失效。
对于 `Load Barrier` 来说,在指令前插入 `Load Barrier`,可以让高速缓存中的数据失效,强制从新从主内存加载数据;
对于 `Store Barrier` 来说,在指令后插入 `Store Barrier`,能让写入缓存中的最新数据更新写入主内存,让其他线程可见。
# Java内存屏障
java 的内存屏障通常所谓的四种即 `LoadLoad`, `StoreStore`, `LoadStore`, `StoreLoad` 实际上也是上述两种的组合,完成一系列的屏障和数据同步功能。
- 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 语义中的内存屏障
volatile 的内存屏障策略非常严格保守,非常悲观且毫无安全感的心态:
- 在每个 volatile 写操作前插入 StoreStore 屏障,在写操作后插入 StoreLoad 屏障;
- 在每个 volatile 读操作前插入 LoadLoad 屏障,在读操作后插入 LoadStore 屏障;
由于内存屏障的作用,避免了 volatile 变量和其它指令重排序、线程之间实现了通信,使得 volatile 表现出了锁的特性。
# final语义中的内存屏障
对于 final 域,编译器和 CPU 会遵循两个排序规则:
新建对象过程中,构造体中对 final 域的初始化写入和这个对象赋值给其他引用变量,这两个操作不能重排序;(废话嘛)
初次读包含 final 域的对象引用和读取这个 final 域,这两个操作不能重排序;(晦涩,意思就是先赋值引用,再调用 final 值)
总之上面规则的意思可以这样理解,**必需保证一个对象的所有final域被写入完毕后才能引用和读取**。
这也是内存屏障的起的作用:
- 写 final 域:在编译器写 final 域完毕,构造体结束之前,会插入一个 StoreStore 屏障,保证前面的对 final 写入对其他线程/CPU 可见,并阻止重排序。
- 读 final 域:在上述规则 2 中,两步操作不能重排序的机理就是在读 final 域前插入了 LoadLoad 屏障。
X86 处理器中,由于 CPU 不会对写-写操作进行重排序,所以 StoreStore 屏障会被省略;而 X86 也不会对逻辑上有先后依赖关系的操作进行重排序,所以 LoadLoad 也会变省略。
>作者:Rinoux
链接:https://www.jianshu.com/p/2ab5e3d7e510
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

【转】内存屏障(Memory barrier)