在Java里并发环境下如何保证对象可见性_Java内存模型原理说明_技术教程

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 引用未被发布出去）。

使用 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，反而更容易掩盖问题。