volatile能保证可见性但不能保证原子性，因其强制写入主内存并使其他线程缓存失效，解决读取最新值问题；但不阻止重排序且无锁机制，无法保障i++等复合操作的原子性。
volatile 为什么能保证可见性但不能保证原子性
因为 volatile 关键字会强制将写操作刷新到主内存，并使其他线程缓存中对应变量的副本失效。下一次读取时，必须从主内存重新加载——这就解决了可见性问题。
但它不阻止指令重排序（仅禁止特定类型的重排序），也不提供锁机制，所以像 i++ 这种“读-改-写”三步操作依然可能被并发打断。
-
volatile适合用在状态标志位，比如private volatile boolean running = true; - 不要用它保护复合操作，例如
counter++或list.add(x) - JVM 对
volatile long和volatile double的读写是原子的（JLS §17.7），但普通long/double在 32 位 JVM 上可能有“半个写”问题
synchronized 和 final 字段的可见性保障机制
synchronized 块的进入和退出，分别对应一个“获取锁”和“释放锁”动作。JMM 规定：释放锁前对共享变量的所有写操作，都必须刷新到主内存；而获取锁后，线程会清空本地工作内存，重新从主内存读取变量值。
final 字段则在构造器完成那一刻起，就对其他线程可见——前提是对象没有发生“逸出”（即构造过程中 this 引用未被发布出去）。
立即学习“Java免费学习笔记（深入）”；
- 使用
synchronized时，锁对象要稳定，避免用String或Integer等可变/可复用对象作为锁 -
final字段只能在构造器或声明时赋值；一旦初始化完成，其引用的对象内容是否可见，取决于该对象自身是否线程安全 - 注意：
synchronized(this)和synchronized(staticMethod)锁的是不同对象，不可混用
Java 内存模型里的 happens-before 规则怎么用
happens-before 不是时间先后，而是一种偏序关系，用来定义哪些操作的结果对另一些操作可见。只要 A happens-before B，那么 A 的执行结果（如变量写入）对 B 就一定可见。
常见规则包括：程序顺序规则、监视器锁规则、volatile 变量规则、线程启动/终止规则等。它们共同构成 JMM 的可见性契约。
- 两个线程分别对同一
volatile变量做写操作，不构成 happens-before 关系，因此不能推导出彼此的写操作可见性 -
Thread.start()happens-before 该线程的任何动作；Thread.join()happens-before 调用方后续操作 - 不要依赖代码书写顺序来判断可见性，比如：先写
a = 1，再写flag = true，若flag非volatile，则其他线程看到flag == true时，a == 1不一定成立
Unsafe.putOrderedXXX 和 VarHandle.setOpaque 的实际意义
这两个 API 提供“无屏障写”（store-store barrier），只禁止写操作被重排序到其后，但不强制刷新到主内存，也不使其他线程缓存失效。性能比 volatile 写高，适用于某些宽松场景，比如队列尾指针更新。
它们不建立 happens-before 关系，所以不能替代 volatile 来解决一般可见性问题。
-
Unsafe.putOrderedInt(obj, offset, value)是 JDK 8 及以前的低层方式；JDK 9+ 推荐用VarHandle.setOpaque(...) - 只有在明确知道读线程会通过其他同步手段（如后续的
volatile读、锁、CAS）来触发缓存同步时，才可用这类“有序写” - 多数业务代码无需接触这些 API；用错会导致极难复现的可见性 bug
// 示例：用 VarHandle 实现无锁计数器的“宽松写”
private static final VarHandle COUNTER;
static {
try {
COUNTER = MethodHandles.lookup()
.findVarHandle(Counter.class, "count", int.class);
} catch (Exception e) {
throw new Error(e);
}
}
private volatile int count = 0;
public void increment() {
// 普通递增仍需同步，这里仅演示 setOpaque 的调用位置
COUNTER.setOpaque(this, ((int) COUNTER.getVolatile(this)) + 1);
}
真正容易被忽略的，是 happens-before 的传递性和组合性——单个规则看似简单，但多个规则嵌套（比如 volatile 读 + synchronized 块 + join）时，边界极易模糊。生产环境里，靠“感觉”加 volatile 或“保险起见”全上 synchronized，反而更容易掩盖问题。 
