volatile不能解决非原子操作的线程安全问题，如value++、flag = !flag等“读—改—写”操作；应改用AtomicInteger等原子类或synchronized锁保障复合操作的原子性。
volatile 不能解决非原子操作的线程安全问题，比如 value++、count = count + 1 这类“读—改—写”三步组合操作。即使变量被 volatile 修饰，多个线程仍可能同时读到旧值、各自计算、再写回，最终导致结果丢失。要避免盲目依赖，关键在于分清场景、选对工具。
识别典型的非原子操作陷阱
以下写法看似简单，实则都不具备原子性，仅靠 volatile 无法保障正确性：
-
flag = !flag—— 先读当前值，再取反，再写入；两线程可能同时读到true，都算出false，最终只写入一次 -
list.add(item)（非线程安全集合）—— 方法内部涉及扩容、索引更新等多步，volatile 修饰 list 引用本身也无济于事 -
counter = counter * 2或任何含运算符的赋值 —— 编译后必拆为至少两次内存访问
用原子类替代 volatile + 普通类型
当需要对整数、布尔、引用等做复合更新时，优先选用 java.util.concurrent.atomic 包中的类型：
- 计数场景：用
AtomicInteger替代volatile int，调用incrementAndGet()、compareAndSet() - 布尔状态切换：用
AtomicBoolean的getAndSet()或lazySet()，比volatile boolean+ 手动逻辑更安全 - 对象引用更新：若需“替换并获取旧值”，用
AtomicReference；若只是发布不可变对象，volatile 引用仍适用
用锁或同步块保护临界区
当操作逻辑复杂、涉及多个变量或需保持一致性时，volatile 不再适用，应升级同步机制：
立即学习“Java免费学习笔记（深入）”；
- 多个字段需同时更新（如账户余额 + 交易流水号），必须用
synchronized或ReentrantLock - 条件判断后执行动作（如“如果余额充足，则扣款”），需原子地检查并修改，volatile 无法提供这种“检查-执行”语义
- 使用
synchronized方法或代码块时，天然具备可见性+原子性+有序性，无需额外加 volatile
明确 volatile 的合理边界
volatile 仍有其不可替代的价值，但必须限定在它真正能起作用的场景：
- 纯状态标志：如
volatile boolean shutdownRequested，仅用于通知，不参与计算 - 一次性安全发布：如单例模式中
volatile static Singleton instance，防止构造过程重排序 - 独立观察：某个线程只写，其他线程只读，且读写之间无逻辑依赖
- 切记：只要操作中出现
=右侧含变量自身（如x = x + 1）、方法调用、或条件分支，就已超出 volatile 能力范围
