java内存可见性依赖硬件机制：总线锁定（高开销，已少用）和mesi缓存一致性协议（主流），jvm通过内存屏障指令（如lock前缀）触发硬件行为，确保volatile读写刷新主内存并使其他核心缓存失效。
Java 中的内存可见性，不是 Java 自己凭空实现的，而是依赖底层硬件机制提供的基础能力。JVM 和 Java 内存模型（JMM）在 CPU 提供的总线锁定和缓存一致性协议之上，做了抽象与规范，让开发者能写出跨平台、行为一致的并发代码。
总线锁定：简单但代价高
当一个 CPU 需要原子地修改某个共享变量时，它会向系统总线发送 LOCK# 信号。这个信号会让其他 CPU 暂停对内存总线的访问，相当于“锁住整条路”。所有 CPU 必须等待该操作完成才能继续读写内存。
- 这种方式能确保操作期间没有其他处理器干扰，变量更新后立刻对所有核心可见；
- 但它影响范围太大：哪怕只改一个 int，也会阻塞其他 CPU 对任意内存地址的操作；
- 现代 CPU（如 Intel 486 之后）已基本弃用纯总线锁，仅在特殊场景（比如未对齐访问、跨越缓存行等）才退化使用。
缓存一致性协议：主流方案，以 MESI 为代表
现代多核 CPU 每个核心都有私有 L1/L2 缓存，数据可能同时存在于多个缓存中。MESI 协议通过给每个缓存行标记状态（Modified、Exclusive、Shared、Invalid），协调各核心之间的读写行为：
当某核心修改一个处于 Shared 状态的变量时，会先向其他核心广播“失效请求”（Invalidate），让它们把对应缓存行置为 Invalid；
其他核心下次读该变量时，发现是 Invalid，就必须从主内存或拥有 Modified 状态的缓存重新加载；
这样就保证了：一旦一个核心写完，其他核心再读，拿到的是最新值——也就是可见性得到了保障。
MESI 不需要锁总线，只靠缓存间通信（如总线嗅探 Bus Snooping）完成同步，效率高得多；
但它的前提是变量能被完整缓存在单个缓存行内；否则仍可能回退到总线锁。
Java 如何利用这些硬件能力？
JVM 并不直接发 LOCK# 或操作 MESI 状态位，而是通过语义指令告诉 CPU：“这里需要可见性保障”。
-
volatile字段的读写，会被编译为带内存屏障（Memory Barrier）的指令，例如lock addl $0x0, (%rsp)（x86 下一种轻量级锁前缀），触发缓存一致性协议动作； -
synchronized块的进入和退出，同样插入屏障，配合 monitor 的 lock/unlock，最终由 JVM 调用操作系统/硬件原语实现； - 这些屏障阻止编译器和 CPU 的重排序，并强制刷新/重载缓存，使修改对其他线程可见。
所以，可见性不是靠 Java “软件模拟”出来的，而是 JVM 把 Java 层语义翻译成能触发硬件一致性机制的指令序列。硬件负责“让数据真正可见”，JMM 负责“定义什么时候必须可见”。
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
