volatile的读写操作本身原子，但i++非原子；它被拆为iload、iadd、istore三步，无互斥保护，导致多线程下丢失更新；内存屏障仅保有序性和可见性，不防竞态；依赖旧值的复合操作均不安全。
volatile 的读写操作本身就是原子的，但 i++ 不是单次读写
Java 规范明确保证：对 volatile 变量的**单次读操作**或**单次写操作**（如 count = 5、int x = count）是原子的。但 i++ 在字节码层面展开为三条独立指令：iload（读）、iadd（算）、istore（写），它本质是三个非原子步骤的组合。
哪怕每个步骤都作用在 volatile 变量上，JVM 也不承诺这三步“不可分割”。线程调度器可能在任意一步后切走 CPU，让另一个线程插进来执行自己的 iload——此时两个线程读到的是同一个旧值。
i++ 在多线程下丢失更新的具体过程
假设 volatile int count = 0，线程 A 和 B 同时执行 count++：
- 线程 A 读取
count == 0（可见性保证它读到最新值） - 线程 B 也读取
count == 0（A 还没写回，B 看到的仍是 0） - A 计算出 1，写回
count = 1（volatile 写，立即刷主存） - B 计算出 1，写回
count = 1（覆盖 A 的结果）
最终 count == 1，而非预期的 2。问题不在于“读不到新值”，而在于“读-算-写”之间没有互斥保护。
为什么 volatile 不能靠加内存屏障来兜住 i++？
volatile 写插入的内存屏障，只禁止其后的读/写被重排序到它前面；读插入的屏障，只禁止其前的读/写被重排序到它后面。它管的是**指令顺序**，不是**执行临界区**。
也就是说，屏障能确保：
– A 写完 count = 1 后，B 一定能看到这个 1（可见性）；
– A 不会把 count = 1 提前到某个无关的 log 输出之前（有序性）；
但它完全不阻止 B 在 A 执行 iload 之后、istore 之前，也执行一次 iload。
这种“时间窗口内的竞态”，必须靠锁或 CAS 这类机制来关闭。
哪些操作看似简单，其实和 i++ 一样踩坑？
所有依赖当前值做计算再写回的操作，都逃不开这个问题：
-
count += 1、count--、count *= 2 -
if (flag) { doSomething(); flag = false; }—— flag 是 volatile，但判断和置 false 是两步，中间可能被其他线程改 -
volatile int[] arr = new int[1]; arr[0]++—— 数组引用可见，但arr[0]本身不是 volatile，++ 完全无保护
真正安全的 volatile 使用，仅限于：赋值、读取、作为状态开关（如 shutdownRequested = true），且不依赖该变量的旧值做任何逻辑分支或计算。
