volatile适用于可见性与有序性场景，如状态标志；synchronized保障原子性、可见性、有序性，适合复合逻辑；atomicinteger等为折中方案。
volatile 和 synchronized 不是“选哪个更好”，而是“在哪种场景下更合适”。性能开销低不等于更安全，安全级别高也不代表必须无脑用。关键看你要解决的是可见性、有序性，还是原子性问题。
volatile 的适用边界：轻量但有硬限制
它只做两件事：让变量修改对所有线程立即可见，禁止编译器和 CPU 对该变量的读写重排序。但它完全不保证原子性——比如 counter++ 这种“读-改-写”三步操作，volatile 无法防止中间被其他线程打断。
- 适合单一写、多读的状态标志，如
private volatile boolean shutdownRequested; - 适合双重检查锁（DCL）中的实例引用，确保对象构造完成后再发布
- 不适合计数器累加、条件依赖赋值（如
if (flag) value = compute();中 flag 和 value 需同步）
synchronized 的能力覆盖：重量但全面
它提供原子性、可见性、有序性三重保障，靠 JVM 的 monitor 机制实现，支持锁升级优化。进入同步块时强制刷新本地内存，退出时强制刷回主内存，天然解决所有共享变量一致性问题。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 适合复合逻辑，比如库存扣减前先校验再更新：
if (stock > 0) stock--; - 适合临界区较长、涉及多个变量或外部资源的操作
- 即使单个变量操作，只要逻辑上不可分割，就该用 synchronized 或其他原子工具
性能开销的真实差异
volatile 开销几乎只来自内存屏障指令，基本可忽略；synchronized 在无竞争时是偏向锁，开销极小，高竞争下可能升级为重量级锁，带来线程挂起/唤醒成本。但现代 JVM（Java 15+）对锁优化已非常成熟，实际压测中，多数业务场景下 synchronized 的吞吐下降并不明显。
- 不要因“synchronized 重”就回避它——误用 volatile 导致的 bug 更难排查
- 高频单变量读写（如开关控制）优先 volatile
- 任何含判断、循环、多步更新的共享状态，直接上 synchronized 或 Atomic 类
安全级别的本质区别
volatile 是“可见性协议”，synchronized 是“执行契约”。前者告诉 JVM：“这个变量别缓存，顺序别乱动”；后者告诉 JVM：“这段代码，任何时候只能一人执行，且进出要同步内存”。所以，volatile 安全级别低不是因为它“弱”，而是它根本没承诺原子性——这不是缺陷，是设计定位。
- 若需求只是“让停止信号及时生效”，volatile 安全且足够
- 若需求是“扣减库存不能超卖”，就必须用能保证原子性的方案
- AtomicInteger 等类是折中选择：无锁 + CAS + volatile，适合简单原子操作，但复杂逻辑仍需 synchronized
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
