volatile读操作开销极小，接近普通变量；写操作有确定性开销，需刷新主内存并执行内存屏障，但远轻于synchronized，适合读多写少场景。
volatile 变量的读写操作在性能上呈现明显不对称性：读操作开销极小，几乎等同于普通变量；写操作则有可观但可控的额外成本。
读操作接近零开销
volatile 读只需一次主内存加载（或缓存一致性协议保障的最新值获取），不触发内存屏障写操作，也不涉及锁竞争或上下文切换。JVM 通常将其编译为一条普通 load 指令加轻量级内存屏障（LoadLoad + LoadStore），对现代 CPU 流水线影响微乎其微。
写操作有确定性开销
每次 volatile 写都强制执行两项关键动作：
- 将新值立即刷新到主内存（而非仅停留在 CPU 缓存行）
- 发出 StoreStore 和 StoreLoad 内存屏障，阻止指令重排并同步其他核心的缓存状态
这会导致缓存行失效（Cache Invalidation）广播，在多核系统中引发总线/互连流量，尤其在高频率写场景下可能成为瓶颈。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
相比 synchronized 仍显著更轻量
volatile 写虽比普通写慢，但远低于 synchronized 块的开销：
- 无线程阻塞、无锁队列管理、无 Monitor 争用
- 无上下文切换，不触发 JVM safepoint 检查
- 在读多写少场景（如状态标志、就绪信号）中，整体吞吐优势明显
实际性能表现取决于硬件与访问模式
在 x86/x64 架构上，volatile 写的 StoreLoad 屏障被映射为 mfence 或等效序列，耗时约 10–30 纳秒；而 synchronized 进入临界区平均耗时常达百纳秒至微秒级。但若多个 volatile 变量被频繁交替写入，会加剧缓存行伪共享（False Sharing），反而拉低性能——此时应考虑填充或重新布局字段。
