volatile写操作通过mesi协议将本核缓存行置为modified并广播invalid消息，使其他核缓存失效；读操作因缓存缺失被迫从主内存或修改核重新加载最新值，从而保证纳秒级可见性。
volatile 关键字本身不提供“秒级刷新”这种时间粒度的控制——它触发的是硬件级的即时同步，不是定时操作。所谓“秒级”，其实是误解；真实效果是：一旦执行 volatile 写，CPU 立即通过缓存一致性协议（如 MESI）使其他核心看到最新值，延迟通常在纳秒到百纳秒量级，远快于任何“秒级”概念。
volatile 禁止指令重排靠内存屏障，不是靠“加关键字”
Java 编译器和 CPU 都可能对无依赖的指令重排序。volatile 不是魔法开关，而是在字节码层面要求 JVM 在读/写该变量时插入特定内存屏障：
- volatile 写之后插入 StoreStore + StoreLoad 屏障：确保前面所有普通写已落缓存，且该写必须先于后续任意读/写执行；
- volatile 读之前插入 LoadLoad + LoadStore 屏障：确保前面所有普通读已完成，且该读的结果必须先于后续任意写生效。
这些屏障由 CPU 硬件执行（如 x86 上生成 lock xchg 指令），会暂停乱序执行流水线，强制顺序语义落地。
刷新缓存靠 LOCK 指令触发缓存行失效，不是“写主内存”
volatile 写不等于“把值立刻刷进主内存”，而是让修改对其他 CPU 核心立即可见，机制如下：
- CPU 执行 volatile 写时，LOCK 指令锁定该变量所在缓存行（64 字节对齐）；
- 向总线广播“我要独占修改”，其他 core 若持有该行副本（Shared/Exclusive 状态），立即将其置为 Invalid；
- 本 core 写入本地缓存，其他 core 下次读该变量时因缓存行失效，必须从 L3 或主内存重新加载——这就完成了“强制可见”闭环。
典型错误用法：只靠 volatile 无法保证复合操作原子性
比如下面代码看似安全，实则仍有重排风险：
❌ 错误示范：a = 1;<br>flag = true; // flag 是 volatile
若无额外约束，CPU 可能先执行 flag = true（触发刷新），再执行 a = 1。另一线程看到 flag == true 时，a 还可能是 0。
✅ 正确做法：用 volatile 仅保护状态标志，并配合内存屏障语义（如 double-check lock 中的 volatile 实例引用），或改用 AtomicInteger、synchronized 等保障复合逻辑。
