volatile变量多线程写操作会相互覆盖，因其仅保证可见性与有序性，不提供原子性或互斥性；如counter=1与counter=2并发执行时后写者胜出；复合操作如counter++更会丢失更新；防覆盖需用AtomicInteger、synchronized或接受最终写胜出语义。
Java 中 volatile 变量在多线程写操作时并不保证不被覆盖——这是对 volatile 的一个常见误解。
volatile 不提供写操作的互斥或原子性保障，它只确保：
- 每次写操作立即刷新到主内存；
- 每次读操作强制从主内存重新加载；
- 写与后续读之间构成 happens-before 关系，从而保障可见性和有序性。
但它完全不阻止多个线程同时执行写操作，因此“后写的值会覆盖先写的值”是正常且预期的行为。
为什么 volatile 无法防止覆盖？
以 volatile int counter = 0; 为例：
立即学习“Java免费学习笔记（深入）”；
// 线程 A 执行 counter = 1; // 写入 1 → 主内存变为 1 // 线程 B 同时执行 counter = 2; // 写入 2 → 主内存变为 2（覆盖了 1）
这两条赋值语句各自是原子的（int 赋值本身是原子操作），但它们之间没有同步机制，也不构成原子组合。结果就是：谁最后写，主内存就保留谁的值 —— 这不是 bug，而是 volatile 的设计本意。
⚠️ 更危险的是复合操作，比如 counter++：
// 这实际是三步：读 counter → +1 → 写回 int temp = counter; // 读（可能读到旧值） temp = temp + 1; // 计算 counter = temp; // 写（可能覆盖别人刚写的新值）
即使 counter 是 volatile，这三步也不构成原子操作，多个线程并发执行时必然丢失更新。
那怎么避免写覆盖？
需要根据场景选择真正能保证原子性或互斥性的方案：
✅ 单次简单赋值（安全）
如状态标志：volatile boolean running = true;running = false;—— 不会“覆盖”，因为只是设为固定值，语义上无需竞态保护。-
✅ 使用 AtomicInteger / AtomicBoolean 等原子类
它们底层用 CAS（Compare-and-Swap）实现无锁原子更新：private AtomicInteger counter = new AtomicInteger(0); counter.incrementAndGet(); // 线程安全的 ++，不会丢失更新
-
✅ 用 synchronized 或 ReentrantLock
对临界区加锁，确保同一时刻只有一个线程执行写逻辑：private int counter = 0; public synchronized void increment() { counter++; // 此时不会被覆盖 } -
✅ 明确接受“最终写胜出”语义的场景
比如配置开关、停机指令、最新状态快照等，本身就不要求中间值不丢失，只要最终值可见即可：volatile String latestConfig; // 多个线程可更新，最后写入者生效，没问题
小结关键点
- volatile 的写操作是“直通主内存”的，但不是排他性的；
- 它不加锁、不阻塞、不协调线程执行顺序；
- “不被覆盖”本质是业务语义需求，而 volatile 只解决“改了能不能被看到”，不解决“能不能同时改”；
- 真正要防覆盖，得靠原子类、锁，或者重构逻辑让覆盖本身无害（例如用时间戳+版本号做乐观更新）。
不复杂但容易忽略：volatile 是信号灯，不是门禁。
