volatile 不修复 long/double 非原子性，仅在旧版32位JVM中保障单次读写原子性；现代64位JVM已默认原子，真正需原子操作应使用AtomicLong，volatile核心价值在于可见性和禁止重排序。
volatile 并不“补救”long/double 的非原子性，它只是在特定历史条件下（主要是 32 位 JVM）对单次读或写操作提供原子性保证——而这本质上是 JVM 实现层面的契约兑现，不是语言层的魔法修复。现代 Java 开发中，你几乎不需要靠它来解决 64 位类型原子性问题。
volatile 对 long/double 的“原子性”仅限于单次读写
Java 语言规范曾明确：在某些 JVM 实现（尤其是旧版 32 位 HotSpot）中，未修饰的 long/double 读写可能被拆成两个 32 位操作，导致线程看到“高低位拼接错误”的值（比如高位是旧值、低位是新值）。volatile 的作用，就是向 JVM 发出信号：“请确保对该变量的每次读或每次写，都作为不可分割的单条指令执行”。
这仅覆盖两种动作：
- 直接赋值：
counter = 100L;→ volatile 使其在 32 位 JVM 上也原子 - 直接读取：
long v = counter;→ 同样原子，不会读到撕裂值
它不覆盖任何复合操作，例如：
立即学习“Java免费学习笔记（深入）”；
-
counter++（读+加+写，三步） -
counter += 5（同上） -
if (counter > threshold) counter *= 2;（含判断和写）
现实环境里，这个“补救”基本已失效
自 Java 5 起，主流 64 位 JVM（如 OpenJDK 8u292+、11、17、21）在 x86_64 或 aarch64 平台上，对 long/double 的普通读写已默认使用单条 CPU 指令（如 mov rax, [mem]），天然原子。即使在部分 32 位环境（如嵌入式 OpenJDK），现代实现也通过 CAS 或总线锁等方式规避撕裂风险。
你可以运行以下代码快速确认当前环境：
System.out.println(System.getProperty("sun.arch.data.model")); // 输出 "64" 或 "32"
若输出为 "64"，则无需为 long/double 的简单读写操心原子性；若为 "32"，且你确实在维护老旧嵌入式系统（如某工业控制器上的 Java ME 或裁剪版 JVM），才需考虑 volatile 的原始用途。
真正需要原子保障时，该用 AtomicLong 而不是 volatile long
当变量用于计数、序列号、状态切换等场景，核心诉求其实是“操作整体不可中断”，而非“单次读写不撕裂”。这时 volatile 不够用，必须升级工具：
-
AtomicLong.incrementAndGet()：硬件级 CAS 指令（如 x86 的cmpxchg8b），从读到写全程原子 -
AtomicLong.compareAndSet(expected, updated)：支持条件更新，volatile 完全无法实现 - 性能上，
AtomicLong.get()和 volatile 读接近；set()略慢（因插入内存屏障）；但incrementAndGet()的安全代价远低于手动加锁
volatile 的真实价值不在“保原子”，而在“保可见”和“禁重排”
它最典型、最可靠的用途是做轻量级状态开关：
-
volatile boolean isRunning = true;—— 线程间快速感知停止信号 -
volatile int configVersion;—— 配置热更新后，所有线程立即读到新版本号
这些场景不要求操作复合，只要求“一写即见、顺序可靠”。volatile 在这里开销小、语义清晰，比 synchronized 更合适。而一旦涉及“读-改-写”，就该交给 AtomicXXX 或锁机制。
