volatile性能优于synchronized，因其无锁且仅依赖轻量级内存屏障；synchronized涉及锁竞争、上下文切换和内存同步，高并发下延迟显著，但能保证多步操作的原子性与正确性。
volatile 读操作几乎无开销，写操作因插入内存屏障略慢但远低于锁；synchronized 涉及锁获取、线程阻塞、上下文切换和内存同步，高竞争下延迟明显。
volatile 的性能优势
volatile 是无锁机制，不引发线程挂起或唤醒。它的核心开销仅来自内存屏障（如 StoreStore、LoadLoad），这些指令在现代 CPU 上代价极低：
- 读取 volatile 变量：基本等同于普通变量读，无额外同步成本
- 写入 volatile 变量：插入写屏障，阻止重排序并强制刷新缓存行，但无需进入操作系统内核态
- 适用于高频读、低频写的场景，例如状态标志、开关控制、双重检查锁中的 instance 引用
synchronized 的运行成本
synchronized 是基于 Monitor 的重量级同步原语，即使 JDK 1.6 后引入偏向锁、轻量级锁优化，其本质仍是互斥机制：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 锁竞争时会触发线程阻塞与唤醒，带来上下文切换开销（微秒级，但高并发下累积显著）
- 每次进入/退出同步块都强制同步工作内存与主内存，涉及多个共享变量的批量刷写
- 锁膨胀（从偏向→轻量→重量）过程本身有额外判断与状态迁移成本
- 不适合细粒度、高频调用，例如循环体内反复加锁
典型场景下的实际表现
在真实压测中（JDK 21+，多核服务器），两者差异清晰可见：
立即学习“Java免费学习笔记（深入）”；
- 单变量状态轮询（如 while(!running)）：volatile 吞吐量可达 synchronized 的 5–10 倍
- 简单计数器自增（i++）：volatile 完全不可用（结果错误），synchronized 虽安全但吞吐受限；此时应改用 AtomicInteger（CAS 实现），性能介于两者之间且线程安全
- 多步协同逻辑（如“检查余额→扣款→更新日志”）：必须用 synchronized 或 ReentrantLock，volatile 无法覆盖原子性需求，强行使用会导致数据错乱
选哪个不是看谁“更快”，而是看是否需要互斥执行。只要逻辑跨步骤、涉多变量、含条件判断，volatile 就不再适用——这时性能让位于正确性，加锁是必要选择。
