Java VarHandle 内存序选择与可见性验证

Java VarHandle 的内存序选择，关键不在于“越强越安全”，而在于先说清楚共享变量要保证什么。只需要单线程语义时用 plain；需要对同一变量保持可观察的顺序时看 opaque；一个线程先写数据、再发布状态，另一个线程读取状态后再读数据时，用 setRelease 配合 getAcquire；需要更强的全局顺序和成熟的并发协议时，再使用 volatile。原子更新则另看 compareAndSet 等操作，不能用“可见”替代“原子”。

内存序不是越强越好，先按保证目标选

VarHandle 的访问模式会覆盖字段声明处的内存语义，所以同一个句柄既不能默认当成 volatile，也不能因为字段本身声明为 volatile 就随意混用 plain 访问。可以把选择压缩成下面这张表：

用 release/acquire 完成一次安全发布

假设生产线程准备好一份不可变配置，再把 ready 标记为 true；消费线程只在 acquire 读到 true 后访问配置。release 负责把之前的写入排在发布动作之前，acquire 负责让后续读取排在观察到发布之后：

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

final class ConfigSlot {
    private Config config;
    private boolean ready;

    private static final VarHandle CONFIG;
    private static final VarHandle READY;

    static {
        try {
            MethodHandles.Lookup lookup = MethodHandles.lookup();
            CONFIG = lookup.findVarHandle(ConfigSlot.class, "config", Config.class);
            READY = lookup.findVarHandle(ConfigSlot.class, "ready", boolean.class);
        } catch (ReflectiveOperationException e) {
            // 句柄初始化失败属于程序配置错误，直接阻止类继续使用。
            throw new ExceptionInInitializerError(e);
        }
    }

    void publish(Config value) {
        CONFIG.set(this, value);          // 先写入完整对象引用。
        READY.setRelease(this, true);     // 再用 release 发布就绪状态。
    }

    Config read() {
        if (!(boolean) READY.getAcquire(this)) {
            return null;                  // 未观察到发布，不读取半成品。
        }
        return (Config) CONFIG.get(this);  // acquire 后读取已发布数据。
    }
}

record Config(String endpoint, int timeoutMillis) {}

这段协议只把 ready 当作发布锚点：生产者必须先完成 config 写入，消费者必须先通过 acquire 读取 ready。如果消费者绕过标志直接读取配置，或者生产者在 release 后继续修改配置，协议就失去边界。

竞争更新要单独处理原子性

如果多个线程要把状态从 0 改成 1，单纯的 get 加 set 即使使用 volatile 也会丢失竞争结果。此时使用 compareAndSet，并把失败重试作为协议的一部分：

boolean claim(VarHandle state, Object receiver) {
    // 只有观察到 0 的线程才能把状态原子地改成 1。
    return (boolean) state.compareAndSet(receiver, 0, 1);
}

compare-and-set 解决的是一次条件更新的原子性；至于更新前后的其他字段能否被对方看到，仍要根据操作的 acquire/release/volatile 变体和整体发布顺序判断。

验证清单：把“偶尔读到新值”变成可检查的保证

1. 先调用 isAccessModeSupported 检查工厂方法返回的句柄是否支持目标模式；不支持时会抛出 UnsupportedOperationException。
2. 为发布标志建立单向约束：所有数据写入必须先于 setRelease，所有数据读取必须位于 getAcquire 之后。
3. 并发测试中重复启动生产者和消费者，断言“观察到 ready 为 true 时配置字段完整”，不要只断言最终计数。
4. 避免在同一变量上混用不匹配的访问模式；如果必须混用，先把每一种操作的顺序语义写在测试名和代码注释里。

延伸问答

opaque 能不能替代 volatile

不能。opaque 强调同一变量的原子和连贯观察，但不提供 volatile 那样的完整顺序保证；它适合对观察强度有明确控制的低层场景。

release 写入后是否所有线程都立刻看到数据

不能这样表述。只有读取端通过匹配的 acquire 观察到同一发布变量，才形成这条发布关系；普通读取不会自动获得同样保证。

VarHandle 能否直接替代锁

不能直接替代。VarHandle 适合小而明确的状态协议，涉及多个字段的一致性、不变量或复杂临界区时，锁通常更容易证明正确。

为什么测试通过仍不能证明 plain 访问安全

一次测试只说明该次调度没有暴露问题。plain 没有跨线程的可见性与排序保证，必须依据 happens-before 关系和访问模式设计来判断。