Java中的内存屏障(LoadLoad/StoreStore)是什么
Java不提供LoadLoad/StoreStore关键字，JVM是基于synchronized的、volatile或Unsafe.loadFence()等语义插入汇编层的内存屏障，具体依赖CPU架构。
Java里没有LoadLoad或StoreStore关键字
Java语言层面根本不暴露LoadLoad、StoreStore这种内存屏障指令——它们是JVM内部CPU指令的翻译结果，不是你可以直接写的语法。你写的synchronized、volatile或者Unsafe.loadFence()，只有JVM才能在生成的汇编中插入相应的屏障。
常见的误解是认为它可以像C++一样手写std::atomic_thread_fence(memory_order_acquire)，但在Java中： -volatile字段读 → 一般情况下，编译后带LoadLoad+LoadStore(取决于平台) -volatile字段写 → 通常带StoreStore+StoreLoad-Unsafe.loadFence()→ 强制插入LoadLoad+LoadStore（HotSpot 其实x86下就是mov %rax, %rax这种空操作，但语义存在)
为什么x86上StoreStore经常被省略
x86 CPU本身有很强的内存顺序保证:写-写-写（Store-Store）自然有序，无需额外指令。因此，Hotspot在x86上编译volatile写时，StoreStore屏障经常被优化，只留下StoreLoad（用lock addl <p>x86 CPU本身有很强的内存顺序保证:写-写-写（Store-Store）自然有序，无需额外指令。因此，Hotspot在x86上编译<code>volatile写时，StoreStore屏障经常被优化，只留下StoreLoad（用lock addl $0,(%rsp)等模拟)。
,(%rsp)等模拟)。
但这并不意味着它不重要： - ARM/Arch64没有这个保证，StoreStore它将被真实地编译成dmb st指令 - 假如你写JNI或使用它Unsafe做底层并发控制，跨平台不能假设StoreStore“不存在” - JMM规范要求语义，不依赖硬件；JVM必须在弱序平台上补充，可以在强序平台上省略——这是实现细节，而不是行为承诺
Unsafe.loadFence()和Unsafe.storeFence()怎么选
这两个是Java 9+最接近底层屏障的公共API，但用错了会浪费精力:
Unsafe.loadFence()：确保在此点之前完成所有阅读，然后阅读不会重新排序到它的前面 → 对应LoadLoad+LoadStoreUnsafe.storeFence()：确保这一点之前所有的写作都完成了，然后写作不会重新排序到它的前面 → 对应StoreStore+StoreLoad- 别用
Unsafe.fullFence()取代前两者——它增加了更多不必要的东西LoadLoad/StoreStore在x86上，组合等于多一个mfence，性能损失明显 - 它们不作用于特定的变量，只是插入指令栅栏；为了保护某个字段，仍然需要配合
volatile或者CAS语义
看到LoadLoad相关错误很有可能理解JMM边界错误
在运行过程中，你看不到它LoadLoad barrier missingJVM不会报告这个错误信息。当真正出现问题时，现象通常是： - 多线程读取未初始化的对象字段(例如final字段被重新排序，看到默认值。 - 在双检锁单例中，构造函数已经执行，但对象已经泄露到其他线程 -@Contended没有生效，伪共享仍然存在这个时候该检查的不是“怎么加”LoadLoad”，而是： - 是否漏了volatile装饰状态标志 - 是否在synchronized本应在锁内发布的块外读取引用 - 是否误以为Thread.start()happenss自动建立-before，忘记了后续的阅读操作没有同步约束 - JVM参数如-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly只有看Java代码，才能看到实际生成的屏障指令。