volatile不解决原子性，仅保障可见性与有序性；它只能保证单次读/写原子，无法防护i++等“读-改-写”复合操作，高并发下易致数据覆盖，需用atomicinteger、synchronized等加固。
volatile 本身不解决原子性问题，只保障可见性和有序性。在高并发写场景下，若仅靠 volatile 修饰计数器、状态标志等变量，却对 i++、count += 1 这类复合操作不做防护，极易发生数据覆盖——多个线程读到同一旧值 → 各自加 1 → 全部写回相同新值，最终结果远小于预期。这不是 volatile 的“失效”，而是误用。
明确 volatile 的能力边界
它只保证单次读/写操作的原子性（如 flag = true），但无法覆盖“读-改-写”三步组成的非原子操作。比如：
volatile int counter = 0;- 线程 A 读 counter = 0 → 计算 0+1 = 1 → 写入 1
- 线程 B 几乎同时读 counter = 0 → 计算 0+1 = 1 → 写入 1
- 结果：counter = 1（本应为 2）
识别高风险复合操作
以下写法看似简单，实则危险，即使变量被 volatile 修饰：
-
value++、value-- -
value += delta、value *= factor -
list.add(item)（若 list 非线程安全） - 依赖当前值做判断再更新，如：
if (status == INIT) status = RUNNING;
这类逻辑本质上是“检查后执行”，volatile 无法阻止两个线程在检查后、执行前发生竞争。
用对工具：替代或加固 volatile
当需要既可见又安全的写操作时，应按场景选择更合适的机制：
-
计数类场景：直接使用
AtomicInteger、AtomicLong等原子类，它们内部用 CAS + volatile 实现无锁原子更新 -
状态切换类场景：用
AtomicBoolean.compareAndSet(expected, new)或AtomicInteger.updateAndGet()确保“读-判-写”整体原子 -
复杂业务逻辑：volatile 仅作状态通知（如
isRunning），实际数据修改仍需synchronized或ReentrantLock保护临界区 - 初始化一次性场景：如双重检查单例中的 instance，volatile 防止构造过程重排序，此时无需原子性，恰是它的正确用武之地
设计阶段就规避陷阱
写多线程代码前，先问自己两个问题：
- 这个变量的每次写入，是否都独立于它当前的值？（即：写操作不依赖读取结果）
- 这个变量是否单独存在，不参与与其他变量构成的不变式？（如：
min 这类约束）
如果任一答案为“否”，就不要指望 volatile 能兜底——它不是锁的廉价替代品，而是轻量级协作信号的专用通道。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
