volatile读后jvm会在其与后续普通读间插入loadload屏障以确保顺序，x86下常优化为空操作，而arm需dsb ish指令开销更高。
Java里哪些操作会隐式插入LoadLoad屏障
在HotSpot JVM中，volatile读本身不单独触发LoadLoad屏障，但它的语义要求：**后续所有普通读必须看到该volatile读之前已从主内存加载的值**。因此JVM会在volatile读之后、下一个普通读之前插入LoadLoad屏障（x86下常被编译为lfence或空操作，因x86天然有强顺序）。
常见误判是以为synchronized块入口/出口会插LoadLoad——其实不会；它保证的是锁获取/释放时的LoadStore和StoreStore（对临界区外的读无强制重排约束）。
-
volatile int x读之后立即读int y，JVM可能插入LoadLoad确保y不被重排到x读之前 - 纯
final字段初始化完成后的读，不触发LoadLoad（由StoreStore保障构造过程可见性） - 使用
Unsafe.loadFence()可显式插入，但仅限JDK9+，且需--add-opens java.base/jdk.internal.misc=ALL-UNNAMED
StoreStore屏障在对象发布场景中为什么关键
对象“逸出”（如写入静态集合、作为参数传给其他线程）前，若字段未完全初始化就暴露引用，其他线程可能看到部分构造的对象。JVM在new对象后、执行构造器前，会插入StoreStore屏障，确保所有字段写操作不被重排到new指令之后——但这个屏障只作用于本线程内部写序，并不保证其他线程立即看到。
真正起作用的是：构造器结束 + volatile写 / 锁释放，组合触发StoreStore + 内存同步语义。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
obj = new MyObj(); list.add(obj);→list非volatile，无同步，其他线程可能看到obj字段默认值 - 安全写法：
obj = new MyObj(); synchronized(lock) { list.add(obj); }→ 锁释放隐含StoreStore，且刷新缓存 - JDK17+可考虑
VarHandle.releaseFence()替代手动屏障，但语义更重，慎用
不同CPU架构下LoadLoad/StoreStore的实际开销差异
x86/x64上LoadLoad和StoreStore多数被优化为空指令（如nop），因为其内存模型天然禁止大多数重排；而ARM/AArch64必须用dsb ish或dmbsy等完整屏障指令，开销高一个数量级。
这意味着：在ARM设备（如Android、Apple Silicon Mac）上，频繁volatile读写或显式Unsafe屏障会显著拖慢性能，而在x86服务器上几乎无感。
- OpenJDK中
OrderAccess::loadload()在x86展开为空，在ARM展开为__asm__ volatile("dsb ish" ::: "memory") - 使用
@Contended减少伪共享，比滥用volatile更能缓解ARM下的性能问题 - CI/CD中做性能对比时，务必在目标架构（而非开发机x86）上压测
为什么不能靠“加volatile”解决所有重排问题
volatile字段读写自带LoadLoad/LoadStore/StoreLoad/StoreStore组合，但它只保护该字段本身，不构成对周围代码的“围栏”。比如volatile写后跟一个普通写，后者仍可能被重排到前者之前（只要不违反volatile语义）——这是很多人踩坑的根源。
- 错误假设：
flag = true; data = 42;→ 改成volatile flag = true; data = 42;就能让data对其他线程可见？不能，data仍是普通变量，无同步保障 - 正确做法：要么
data也声明为volatile，要么用锁包裹两行，或用VarHandle.setRelease()配getAcquire() - JSR-133规范明确：
volatile写仅建立与后续volatile读之间的happens-before，不自动传播到非volatile访问
屏障不是魔法开关，它只约束特定指令间的顺序关系；真正决定可见性的，是happens-before链是否闭合。这点最容易被忽略，也最难调试。
