Java 规范保证 int 等基本类型读写具有原子性，但这仅确保操作“不可分割”，并不保证一个线程对变量的修改能及时被其他线程观察到；可见性必须由 volatile、锁或同步机制显式保障。
java 规范保证 `int` 等基本类型读写具有原子性，但这仅确保操作“不可分割”，并不保证一个线程对变量的修改能及时被其他线程观察到；可见性必须由 `volatile`、锁或同步机制显式保障。
在 Java 并发编程中，原子性（Atomicity） 和 可见性（Visibility） 是两个正交且常被混淆的核心概念。理解它们的区别，是写出正确、高效多线程代码的前提。
✅ 原子性：操作“不可中断”，但不等于“即时可见”
Java 语言规范（JLS §17.7）明确规定：对除 long 和 double 外的所有基本类型（如 boolean、byte、char、short、int、float）的单次读/写操作，是默认原子的。这意味着：
- 对 int 变量的赋值（如 counter = 42;）或读取（如 int x = counter;）不会出现“只写入/读取了低 16 位”的中间态；
- 即使在 32 位 JVM 上，int（32 位）也能在一个 CPU 指令周期内完成，天然避免撕裂（torn write/read）。
public class AtomicityDemo {
private int value = 0;
// ✅ 线程安全的原子写（无撕裂风险）
public void setValue(int v) { value = v; }
// ✅ 线程安全的原子读（返回完整值）
public int getValue() { return value; }
}⚠️ 但请注意：原子性 ≠ 可见性。即使 value 的每次读写都是原子的，JVM 和 CPU 仍可能因以下原因导致其他线程看不到最新值：
- 编译器重排序（如将循环中不变的读取提到循环外）；
- CPU 缓存一致性延迟（线程 A 修改了主内存中的 value，但线程 B 仍从本地 CPU 缓存中读取旧值）；
- JIT 运行时优化（例如将 while (flag == false) 优化为死循环，因未观测到 flag 在别处被修改）。
❌ 典型反例：缺少 volatile 导致无限循环
以下代码看似简单，却存在严重可见性问题：
立即学习“Java免费学习笔记（深入）”；
public class VisibilityProblem {
private boolean flag = false;
public void setFlag() {
flag = true; // 原子写，但不保证对其他线程可见
}
public void waitForFlag() {
while (!flag) { // ⚠️ 可能永远循环！JIT 可能缓存 flag 值
Thread.onSpinWait();
}
System.out.println("Flag is now true!");
}
}即使 flag 是 boolean（原子类型），若未声明为 volatile，线程 B 执行 waitForFlag() 时，完全可能永远读不到线程 A 写入的 true —— 因为 JVM 允许将 flag 缓存在寄存器或线程本地缓存中，且不强制刷新。
✅ 正确做法：用 volatile 显式建立happens-before 关系：
private volatile boolean flag = false; // ✅ 同时提供原子性 + 可见性 + 禁止重排序
此时：
- 所有对该变量的读写都具有原子性（对 boolean 本就成立，但 volatile 强化语义）；
- 写操作对所有后续读操作可见（setFlag() happens-before waitForFlag() 中的 while 判定）；
- 编译器和 CPU 不得对该变量的读写进行重排序。
? 补充说明：为何 long/double 需要 volatile 保原子性？
对于 64 位的 long 和 double，JLS 允许 JVM 将其拆分为两个 32 位操作（尤其在 32 位平台）。这会导致撕裂读写（torn read/write）：
// 线程 A 写入 0x12345678_9ABCDEF0 sharedLong = 0x12345678_9ABCDEF0; // 线程 B 同时读取 → 可能得到 0x12345678_12345678（高低位来自不同写入） long observed = sharedLong; // ❌ 非预期值！
而 volatile long 强制 JVM 以原子方式处理整个 64 位，同时一并解决可见性与重排序问题。
✅ 总结：何时需要 volatile？
| 场景 | 是否需要 volatile | 原因 |
|---|---|---|
| 单线程访问 | ❌ 不需要 | 无并发，无需可见性保证 |
| 多线程读写，且需立即可见（如状态标志、停止信号） | ✅ 必须 | 提供可见性 + 禁止重排序 |
| 多线程读写，但操作非原子（如 i++） | ❌ volatile 不够 | i++ 包含读-改-写三步，需 synchronized 或 AtomicInteger |
| long/double 多线程读写 | ✅ 强烈推荐 | 同时保障原子性 + 可见性 |
? 关键口诀：
“原子性管‘怎么写’，可见性管‘写完谁看见’；volatile 二者兼得，但绝不替代锁来保护复合操作。”
正确使用 volatile 是构建轻量级线程协作的基础，但它不是万能解药。理解其边界，才能在性能与正确性之间做出专业权衡。
