Java中volatile写操作前为何无需LoadStore屏障（JSR-133规则）

核心疑问拆解 #

你纠结的点在于：JMM明确禁止普通Load与后续的volatile-Store重排序，但为何仅要求在volatile-Store前插入StoreStore屏障，而非同时插入LoadStore屏障？担心没有LoadStore的话，volatile-Store会被重排到普通Load之前，违反规则。

关键原因解析 #

1. 编译器层面直接约束，无需依赖LoadStore屏障

JSR-133对编译器有明确规则要求：禁止将volatile-Store指令重排到前面的普通Load指令之前。这是编译器必须遵守的语义约束，不需要靠硬件屏障强制。比如你写的代码是：

int val = ordinaryVar; // 普通Load
volatileVar = 1; // volatile-Store

编译器绝对不会把volatileVar = 1移到int val = ordinaryVar前面，这是编译阶段就会保证的顺序，和LoadStore屏障无关。

2. StoreStore屏障的作用是解决可见性，而非Load-Store顺序

StoreStore屏障的核心目的是保证：所有在屏障之前的普通Store操作，必须在volatile-Store执行前刷入主内存。这是为了满足volatile写的可见性语义——当其他线程读取这个volatile变量时，能看到之前所有普通变量的修改结果。

比如这段代码：

ordinaryVar = 5; // 普通Store
volatileVar = 1; // volatile-Store

插入StoreStore屏障后，能确保ordinaryVar=5的写操作先刷到主内存，再执行volatileVar=1，避免其他线程看到volatileVar=1时，ordinaryVar还是旧值。

3. 主流硬件本身保证Load-Store顺序

像x86这类主流CPU的内存模型（TSO），本身就不允许Store操作越过前面的Load操作执行，硬件层面天然保证了Load在前、Store在后的顺序不会被打乱。对于少数允许LoadStore重排的架构，编译器会通过其他指令调整方式来遵守JMM规则，而非依赖LoadStore屏障。

总结 #

普通Load与后续volatile-Store的顺序问题，是编译器直接通过语义规则锁死的；而StoreStore屏障是专门用来解决普通Store与volatile-Store之间的可见性传递问题，两者作用场景完全不同，因此不需要额外插入LoadStore屏障。

内容的提问来源于stack exchange，提问作者jysun