volatile修饰的变量在i++场景下线程不安全，因为i++包含读、改、写三步非原子操作，volatile仅保证可见性和禁止部分重排序，无法避免竞态条件。
volatile 修饰的变量在 i++ 场景下为什么还是线程不安全
因为 i++ 不是原子操作，而 volatile 只保证可见性和禁止指令重排序，不保证读-改-写过程的原子性。
典型现象是：100 个线程各执行 100 次 i++，最终 i 值远小于 10000 —— 这不是偶发 bug，是必然结果。
-
i++实际拆成三步：read（从主存读值到线程工作内存）、add（+1）、write（写回主存） -
volatile能确保每次read都看到最新值、每次write立即刷回主存，但无法阻止两个线程同时读到相同旧值、各自加 1、再同时写回 - 这种“竞态条件”发生在 CPU 指令级别，JVM 或硬件不会自动加锁保护
哪些操作 volatile 确实能保原子性
仅限对基本类型（boolean、int、long、float、double）的**单次读或单次写**，且 long/double 在 32 位 JVM 上需注意非原子性风险。
- 安全：
flag = true、count = 100、if (running) { ... } - 不安全：
i += 1、i--、a[i] = b[i] + 1、任何含计算或复合逻辑的赋值 -
volatile long在 64 位 JVM 上读写是原子的；但在某些 32 位 JVM（如旧版 Android ART）上，可能被拆成两次 32 位操作，导致“半个 long”被读到
替代方案选型：什么时候用 AtomicInteger，什么时候加 synchronized
核心看是否需要「复合操作的原子性」——比如先检查再更新、累加带条件判断等。
- 纯计数/累加（如统计请求数）：优先用
AtomicInteger，底层靠 CAS，无锁、性能好 - 涉及多个变量协同更新（如余额扣减 + 订单状态变更）：必须用
synchronized或ReentrantLock，否则即使每个变量都volatile也救不了 - 用
AtomicInteger.compareAndSet()实现自旋逻辑时，注意避免高竞争下的 CPU 空转；极端场景下synchronized反而更稳
一个容易被忽略的坑：volatile 不能防止重排序带来的逻辑错乱
它只禁止特定类型的重排序（如写 volatile 后面的普通写不能上移），但不保证所有语句顺序。常见误用是把初始化和标志位设置分开写。
- 错误写法：
context = new Context();→inited = true;，其他线程看到inited == true时，context可能还没构造完（对象引用已发布，但字段仍为默认值） - 正确做法：用
final字段保证构造安全，或直接用AtomicReference<context></context>的lazySet()/set()配合双重检查锁 - 哪怕加了
volatile，也不代表“这段代码执行完了”，只是“这个变量的写操作对其他线程可见了”
并发问题从来不在表面语法，而在执行路径的交错点。volatile 是工具，不是保险丝。真正安全的边界，得靠你对每行代码在多线程下可能怎么跑，心里有数。
