volatile不能保证原子性，i++存在并发风险

volatile关键字虽能保证变量的可见性和禁止部分指令重排序，却无法解决i++这类复合操作（读-改-写）的原子性问题，导致多线程环境下必然出现竞态条件——例如100个线程各执行100次i++，结果远小于预期的10000；它仅对单次读或单次写（如flag = true）提供原子保障，而涉及计算、条件判断或多变量协同的操作必须依赖AtomicInteger、synchronized或Lock等真正具备原子语义的机制；更需警惕的是，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 的 lazySet() / set() 配合双重检查锁
• 哪怕加了 volatile，也不代表“这段代码执行完了”，只是“这个变量的写操作对其他线程可见了”

并发问题从来不在表面语法，而在执行路径的交错点。volatile 是工具，不是保险丝。真正安全的边界，得靠你对每行代码在多线程下可能怎么跑，心里有数。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。