volatile修饰的int自增不是原子操作，因为i++包含读取、加1、写回三步，volatile仅保证可见性和有序性，不保证复合操作的原子性。
volatile 修饰的 int 自增为什么不是原子操作
因为 i++ 是三步：读取、加1、写回，volatile 只保证每次读取都是最新值、每次写入都立即刷到主存，但不阻止多个线程在“读取→计算→写回”之间穿插执行。
- 现象：
volatile int count = 0;在多线程下执行 1000 次count++，最终结果大概率小于 1000 - 原因：两个线程同时读到
count == 5，各自加 1 得到 6，再先后写回，结果只加了 1 次 - 对比：
AtomicInteger.incrementAndGet()把这三步用 CAS 封装成一个不可分割的操作
volatile 能防止指令重排序，但不解决数据竞争
编译器和 CPU 可能对无依赖的语句重排序，volatile 写操作会插入内存屏障，禁止其后的读/写被提到它前面；读操作则禁止其前的读/写被挪到它后面。但这只是“顺序可见性”，不是“执行互斥性”。
- 典型误用：用
volatile boolean initialized = false;配合普通对象字段做双重检查单例，但没把对象引用本身也声明为volatile - 问题：JVM 可能把构造函数内联后重排序，导致其他线程看到
initialized == true，但对象字段还没初始化完 - 正解：必须
volatile Object instance;，且初始化赋值语句（如instance = new Singleton();）本身就是 volatile 写
volatile 和 synchronized 的关键区别在哪
volatile 解决的是变量的“可见性”和“有序性”，synchronized 还额外提供“原子性”和“互斥性”。它们不是替代关系，而是能力交集很小的两种机制。
- 性能：volatile 读几乎无开销，写比 synchronized 轻量得多；但一旦涉及复合操作（如先读后写），volatile 就无能为力
- 锁升级：synchronized 在无竞争时是偏向锁，竞争后可能膨胀为重量级锁；volatile 始终不阻塞线程
- 适用边界：仅当满足“单个变量读/写 + 无依赖于当前值的更新”时，volatile 才安全，例如状态标志位
volatile boolean shutdownRequested
哪些场景下 volatile 看似有效实则危险
最容易掉坑的是把 volatile 当成“轻量级同步”，尤其在涉及多个变量协作或条件判断时。
立即学习“Java免费学习笔记（深入）”；
- 错误示例：
volatile int x, y;然后线程 A 写x=1; y=2;，线程 B 读if (y == 2) System.out.println(x);—— 不能保证看到x==1，因为 volatile 不保证跨变量的顺序约束 - 更隐蔽的问题：volatile 数组引用（如
volatile int[] arr）只保证 arr 引用本身的可见性，数组元素仍可被并发修改而无保护 - 注意：volatile 不能用于
long或double的非原子读写（虽然 JVM 通常已保证，但规范未强制），若需绝对安全，仍建议用 AtomicLong 等
真正难的不是记住 volatile 的定义，而是判断某个具体读写序列里，有没有隐藏的“读-改-写”依赖或跨变量时序假设。这种地方一错，问题往往偶发、难复现、难调试。
