原子性指对其他线程不可见中间状态，如++i非原子因含iload、iinc、istore三步；可见性失效源于缓存与重排序，volatile可强制可见但不保证复合操作原子性；有序性由happens-before规则保障，三者常相互关联。
原子性不是“不可分割”，而是“对其他线程不可见中间状态”
很多人误以为 ++i 是原子操作，其实它在 Java 中对应三条字节码：iload、iinc、istore。多线程下，两个线程可能同时读到旧值，各自加 1 后写回，结果只加了一次。
真正能保证原子性的，是 java.util.concurrent.atomic 包里的类，比如 AtomicInteger 的 incrementAndGet() 方法——它底层依赖 CPU 的 CAS（Compare-And-Swap）指令，失败就重试，整个过程对其他线程表现为“要么没发生，要么全做完”。
注意：synchronized 或 Lock 能“用互斥模拟原子性”，但本质是阻塞+串行，不是原子指令；而 AtomicInteger 是无锁的、非阻塞的原子性。
可见性失效的根本原因是缓存与重排序
一个线程修改了普通变量 flag = true，另一个线程可能一直读到 false——这不是 JVM bug，而是因为：① 线程可能从自己的 CPU 缓存或寄存器读值，没及时从主内存刷新；② 编译器/JVM 可能把读操作提前、把写操作延后，只要单线程语义不变。
立即学习“Java免费学习笔记（深入）”；
强制可见性的办法有三个：
-
volatile关键字：禁止该变量的指令重排序，并且每次读都从主内存取，每次写都立即刷回主内存 - synchronized 块的解锁操作会刷新所有共享变量到主内存，加锁操作会清空本地工作内存（即强制重读）
- 显式使用
VarHandle的loadOpaque()/storeOpaque()或更强的fullFence()
注意：volatile 不保证复合操作的原子性（如 volatile int count; 不能靠它做 count++），只保单个读/写可见。
有序性靠 happens-before 规则定义，不是“代码顺序执行”
Java 内存模型（JMM）不保证代码写的顺序就是运行时执行顺序。比如：
int a = 1; int b = 2; int c = a + b;
编译器可能把 a=1 和 b=2 换序，只要不影响本线程结果；但若另一线程依赖 a 和 b 都写完才读，那就必须建立 happens-before 关系。
常见 happens-before 关系包括：
- 程序顺序规则：同一个线程中，前面的操作 happens-before 后面的操作
- 监视器锁规则：unlock happens-before 后续的 lock
- volatile 变量规则：对 volatile 变量的写 happens-before 后续对它的读
- 线程启动规则：Thread.start() happens-before 子线程的任意动作
- 线程终止规则：子线程所有动作 happens-before join() 返回
没有 happens-before 关系的操作，JVM 就可以重排序——这是性能优化的基础，也是并发 bug 的温床。
三者从来不是孤立存在，改一个常牵动另外两个
比如用 synchronized 修饰方法，它同时提供：原子性（临界区互斥）、可见性（解锁刷主存）、有序性（解锁和加锁构成 happens-before）。
又比如 volatile：它单独提供可见性和有序性（禁止相关重排序），但不提供原子性；若想用它实现计数器，必须配合 CAS 循环（如 AtomicInteger.weakCompareAndSet()）。
最容易被忽略的是：final 字段的特殊语义——构造器内对 final 字段的写，与对象引用的发布之间存在 happens-before（前提是构造过程没发生 this 逃逸）。这意味着正确发布的对象，其 final 字段对其他线程天然可见且不可变。
