volatile能避免脏读，但仅限单次读/写操作；它不解决“读-改-写”复合操作的并发问题，如i++仍会导致数据丢失，需用atomicinteger或synchronized保障原子性。
volatile 能避免脏读，但前提是操作本身是单次读或单次写——它不解决“读-改-写”这类复合操作的并发问题。脏读在这里指一个线程读到过期值（比如其他线程已改但本线程还没看到），而 volatile 正是为解决这个设计的；但它不能防止多个线程基于同一个过期值做修改，导致结果丢失。
volatile 如何保证可见性、从而避免脏读
当一个线程修改了 volatile 变量，JVM 会强制将新值立即刷入主内存；其他线程每次读该变量时，都绕过本地工作内存，直接从主内存加载最新值。这就切断了“缓存不一致”路径，消除了脏读根源。
- 普通变量：线程 A 修改后可能滞留在 CPU 缓存中，线程 B 仍读旧值 → 脏读发生
- volatile 变量：线程 A 写完即同步到主内存，线程 B 下次读必取新值 → 脏读被拦截
哪些场景下 volatile 确实能防脏读
适用于“写不依赖当前值”的简单状态通知或只读发布场景：
- 状态标志控制循环：如
volatile boolean running = true，stop() 设为 false 后，所有 while(running) 线程立刻退出 - 单次赋值的结果发布：如
volatile String latestMsg，生产者 set 一次，多个消费者读取最新消息 - 双重检查单例中的 instance：volatile 防止 new Singleton() 的指令重排，确保其他线程看到的是构造完成的对象，而非半初始化状态
为什么 i++ 这类操作用了 volatile 还会脏读
因为 i++ 不是原子操作，它拆成三步：读 i → 加 1 → 写回 i。volatile 只保障每一步的可见性，不保障三步整体不可分割。
- 线程 A 读 i=5 → 计算得 6 → 尚未写回
- 线程 B 同时读 i=5（此时 A 还没写，主内存仍是 5）→ 也计算得 6 → 写回
- 最终 i=6，而不是预期的 7 → 表面看是“读到了旧值”，实质是“基于旧值做了重复更新”
这不是 volatile 失效，而是误把它当成了原子操作的替代品。
真正需要防脏读+保结果正确时，该用什么
若变量的写操作依赖其当前值（如计数、状态切换、条件更新），就必须引入原子性保障：
- 计数器：用
AtomicInteger.incrementAndGet()，底层 CAS + volatile，一次完成读-改-写 - 状态切换：用
AtomicBoolean.compareAndSet(true, false)，确保“检查+设置”不可中断 - 复杂逻辑：volatile 仅作信号（如 isReady），实际数据变更仍需
synchronized或ReentrantLock包裹临界区
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
