volatile仅保证可见性和有序性，不保证原子性；其单次读写原子性源于jvm规范对基本类型操作的统一要求及内存屏障约束，而i++等复合操作因含“读—算—写”三步仍非原子。
volatile 变量的单次读写操作具备原子性，但这不是由 volatile 本身“实现”的原子保障，而是 JVM 规范对基本类型读写行为的统一要求 + volatile 对内存访问方式的约束共同作用的结果。
volatile 不参与原子性“增强”，只是不破坏它
Java 规范明确：对 boolean、byte、char、short、int、float 类型变量的单次读或单次写操作，本身就是原子的（即不会被线程调度打断）。从 Java 5 开始，long 和 double 的单次读写也被保证为原子操作——前提是它们没有被声明为 volatile（注意：这个“前提”常被误解；实际是：即使没加 volatile，JVM 也必须保证其原子性；而加了 volatile 后，不仅原子，还附带可见性和禁止重排序）。
所以 volatile 并没有“赋予”原子性，它只是在这些本就原子的操作上，叠加了内存语义约束：
- 读操作：强制从主内存加载最新值，不使用工作内存缓存；
- 写操作：强制将新值立即刷入主内存，不滞留在工作内存中。
为什么 i++ 这类操作依然不原子？
i++ 看似简单，实则是三步组合：
- 从主内存/工作内存读取 i 的当前值（原子）；
- 在 CPU 寄存器中执行 +1（非内存操作，不涉及 volatile）；
- 将结果写回变量 i（原子写，但写的是旧读+1后的值）。
问题出在“读—算—写”之间没有同步保护。两个线程可能同时读到 i=5，各自算出 6，再先后写回——最终结果仍是 6，而非预期的 7。volatile 能确保每次读都看到最新值、每次写都立刻发布，但无法让这三步变成一个不可分割的整体。
底层靠什么支撑“单次读写原子性”？
现代 JVM 在 x86/ARM 等主流平台会尽量将 int、long 等类型的读写编译为一条机器指令（如 mov），这类指令天然具有原子性（CPU 层面保证）。JVM 规范要求这种原子性对程序员透明，volatile 则在此基础上插入内存屏障（Memory Barrier），阻止编译器和处理器对 volatile 读写做重排序，并强制刷新/加载动作。
例如：volatile int counter = 0;
counter = 42; → 编译为带 StoreStore 屏障的写指令，原子写入且立即对其他线程可见；
int x = counter; → 编译为带 LoadLoad 屏障的读指令，原子读取且一定来自主内存。
需要原子性时该用什么？
如果业务逻辑依赖复合操作的原子性（如计数、状态切换、条件更新），仅靠 volatile 不够：
- 计数场景优先用 AtomicInteger 等原子类（内部基于 CAS + volatile）；
- 复杂逻辑用 synchronized 或 ReentrantLock；
- volatile 适合做状态标志、一次性发布、轻量级通知等“纯读写”用途。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
