volatile通过强制读写直连主内存、插入内存屏障、触发缓存一致性协议三步协同，迫使其他线程每次读都从主内存获取最新值，写则立即刷回并使其他核缓存失效，形成硬件级可见性通路。
volatile 通过强制读写直连主内存、插入内存屏障、触发缓存一致性协议三步协同，让其他线程“不得不”看到最新状态，不是通知，而是迫使同步。
每次读都绕过本地缓存，直接拉主内存最新值
线程读 volatile 变量时，JVM 禁止复用工作内存（如 CPU 缓存或寄存器）里的旧副本。它会生成 LoadLoad + LoadStore 内存屏障，确保该读操作不被重排，并强制从主内存加载——哪怕其他线程刚写完一毫秒，这次读也一定拿到那个新值。
- 普通变量可能被 JIT 编译器优化成“常量缓存”，比如 while (!flag) 被编译为无限跳转；volatile 切断这种优化路径
- 即使 CPU 缓存中还存着旧 flag=false，读操作也会忽略它，主动触发总线嗅探去主内存取
每次写都立即刷回主内存，并让其他核缓存失效
线程写 volatile 变量后，JVM 插入 StoreStore + StoreLoad 屏障：前者确保上面所有普通写已落盘，后者最关键——它向 CPU 发出信号，把新值写入主内存，同时通过 MESI 协议将其他 CPU 核心中该变量所在的缓存行标记为 Invalid（无效）。
- 其他线程下次读该变量时，因缓存行失效，CPU 自动发起请求，从主内存或共享缓存中获取最新值
- 这个过程是硬件级的，不需要 JVM 主动“发消息”或“轮询”，靠的是缓存一致性机制自动完成
内存屏障 + 硬件协议，共同构成可见性链条
volatile 的可见性不是靠软件层通知实现的，而是 JVM 与 CPU 协同构建的一条确定性数据通路：
立即学习“Java免费学习笔记（深入）”；
- 写线程：写变量 → StoreLoad 屏障 → 刷主内存 + 广播失效信号
- 读线程：读变量前 → LoadLoad 屏障 → 检查缓存行状态 → 若失效则强制重载主内存
- 整条链路由 x86 的 mfence/sfence/lfence 或 ARM 的 dmb 指令支撑，底层有 MESI、MOESI 等协议保障
它不“通知”，只“制造必须重读的条件”
volatile 不会调用回调、不唤醒等待线程、不发送事件。它的“通知”本质是破坏缓存有效性——让其他线程下一次读该变量时，硬件层面无法走缓存命中，只能重新同步。这是一种被动但强保证的可见性机制，适用于状态标志、初始化完成标记等一写多读场景。
