Java VarHandle 怎样用 acquire 和 release 建立可见性边界-Golang学习网

我第一次把 VarHandle 用在“先准备数据、再发布状态”的并发场景时，最容易混淆的是：acquire 和 release 并不是两个可以随意贴在任意读写上的性能开关。真正的边界来自同一个状态变量：写入方先完成数据写入，再对状态做 setRelease；读取方用这个状态的 getAcquire 观察到发布值后，后续读取才处在对应的排序关系中。

官方资料：https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/invoke/VarHandle.html

最小判断标准是：release 写和 acquire 读必须作用在同一个 VarHandle 所指向的变量上；读取方必须真正读到由 release 写出的状态值，不能只把两个方法名分别换上去。

先区分四种访问模式的排序强度

VarHandle 让同一个变量拥有多组访问方式。get 和 set 是 plain 访问，不主动提供跨线程的可观察排序；getOpaque 和 setOpaque 保证对同一变量的连贯访问，但约束仍然比 acquire/release 弱；getAcquire 与 setRelease 用一对方向相反的访问建立发布关系；volatile 访问则提供更强的总排序语义。

模式	典型方法	应该关注什么
Plain	`get` / `set`	适合单线程或同步关系已经由别处保证的访问，不要把它当发布标记。
Opaque	`getOpaque` / `setOpaque`	关注同一变量的连贯观察，但不要据此推断其他字段已经发布。
Acquire/Release	`getAcquire` / `setRelease`	用状态变量连接“之前的写入”和“之后的读取”。
Volatile	`getVolatile` / `setVolatile`	需要更强的全局排序或不想维护精确配对时使用，代价和语义都更重。

Java VarHandle plain opaque acquire release volatile 访问模式排序边界对比说明图 — 图1：VarHandle 访问模式的边界说明图，对比 plain、opaque、acquire/release 和 volatile 的静态语义，不是性能测试结果。

我在排查这类代码时不会先比较“哪个更快”，而是先问：需要发布的是哪个状态？数据是否必须在状态变为可见后才能读取？如果这两个问题没有答案，先换访问模式往往只会把问题藏起来。

用同一个状态变量发布数据

下面的例子把 payload 当作要发布的数据，把 ready 当作发布标记。写入线程使用普通字段写入数据，再用 setRelease 写入 ready；读取线程反复用同一个 readyHandle 做 getAcquire，确认状态为 true 后才读取 payload。

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

final class MessageBox {
    private String payload;
    private boolean ready;

    private static final VarHandle PAYLOAD_HANDLE;
    private static final VarHandle READY_HANDLE;

    static {
        try {
            MethodHandles.Lookup lookup = MethodHandles.lookup();
            // 两个句柄分别定位数据字段和发布状态字段。
            PAYLOAD_HANDLE = lookup.findVarHandle(MessageBox.class, "payload", String.class);
            READY_HANDLE = lookup.findVarHandle(MessageBox.class, "ready", boolean.class);
        } catch (ReflectiveOperationException e) {
            // 句柄初始化失败属于程序配置错误，不能带着半初始化状态继续运行。
            throw new ExceptionInInitializerError(e);
        }
    }

    void publish(String value) {
        // 先写入要发布的数据，再用同一个状态句柄发出 release 信号。
        PAYLOAD_HANDLE.set(this, value);
        READY_HANDLE.setRelease(this, true);
    }

    String awaitPayload() {
        // 只有观察到 release 写入的 true，后续读取才进入 acquire 侧。
        while (!(boolean) READY_HANDLE.getAcquire(this)) {
            // 自旋只用于演示配对关系；生产代码要结合等待时长选择阻塞或退避。
            Thread.onSpinWait();
        }
        // acquire 读取之后再读 payload，避免把“看到 ready”与“读到数据”拆开。
        return (String) PAYLOAD_HANDLE.get(this);
    }
}

这里最关键的不是把 payload 改成 volatile，而是把 ready 作为连接两侧的同步变量。Oracle 对访问模式的描述是：acquire 读取及其后续访问会排在匹配的 release 写入及其之前访问之后。换句话说，setRelease 前对 payload 的写入，能够通过同一个 ready 的匹配读取向后传递。

Java VarHandle 用 payload 和 ready 建立 setRelease 与 getAcquire 可见性边界的静态结构图 — 图2：VarHandle 发布数据的静态结构图，展示 payload、ready、setRelease 和 getAcquire 的职责边界，不是运行截图。

配对时要看变量，不要只看方法名

下面几种写法看起来都出现了 acquire/release，但语义并不等价：

配对同一个变量：写方对 ready 调用 setRelease，读方也必须对同一个 ready 调用 getAcquire。如果一个读的是 version，另一个写的是 ready，方法名再漂亮也没有形成目标发布关系。
读到发布值：读取方只调用一次 getAcquire，如果结果仍是 false，就不能声称已经看到写方发布的数据。循环、条件等待或上层同步机制必须明确处理这个状态。
把方向理解反：setRelease 约束的是它之前的读写不能被重排到该访问之后；getAcquire 约束的是它之后的读写不能被重排到该访问之前。它们的方向相对，不能把 getAcquire 当成“让前面的代码先完成”的按钮。
区分原子性和可见性：访问模式同时涉及原子性、连贯性和排序。acquire/release 解决的是发布关系，不会自动把一个复杂的多字段更新变成事务，也不会替代 compare-and-set 的竞争仲裁。

不生效时按四层检查

如果读线程偶尔拿到旧数据，我会按下面的顺序排查，而不是直接把所有访问替换成 volatile。

变量层：确认 release 写和 acquire 读来自同一个状态变量句柄，坐标对象也确实指向同一个实例或数组元素。
时机层：确认数据写入发生在 setRelease 之前，数据读取发生在读方观察到发布状态之后。
模式层：检查中间是否混入了 plain、opaque 或错误方向的访问；混合访问会让 Java 内存模型允许出现难以直觉解释的结果。
类型层：确认句柄支持目标访问模式、坐标类型和变量类型都匹配。访问模式不支持时会抛出 UnsupportedOperationException，调用点签名不匹配时可能得到 WrongMethodTypeException。

尤其要注意，VarHandle 的方法是签名多态的，调用点参数并不是普通方法那样在编译期完全检查。对字段句柄来说，实例坐标必须放在参数前面；对数组元素句柄，还要带上数组对象和索引。出现异常时，先看 accessModeType 和 isAccessModeSupported，通常比继续改内存模式更快。

VarHandle.AccessMode mode = VarHandle.AccessMode.SET_RELEASE;
// 先确认目标句柄支持该访问模式，再决定是否调用。
if (!READY_HANDLE.isAccessModeSupported(mode)) {
    throw new IllegalStateException("当前句柄不支持 setRelease");
}

// 访问类型包含坐标和写入值，调试签名不匹配时可先打印它。
System.out.println(READY_HANDLE.accessModeType(mode));

发布前的检查清单

需要发布的数据是否都写在 setRelease 之前？
读方是否用同一个状态变量的 getAcquire，并且确实观察到发布值？
是否把“可见性”误当成了“互斥”或“复合更新原子性”？
句柄的变量类型、坐标类型和访问模式是否匹配？
是否有明确的等待、退避或超时策略，避免示例里的自旋无限持续？

几个容易混淆的问题

acquire/release 能完全替代 volatile 吗？

不能直接这样判断。它们提供的排序强度和使用方向不同。能明确设计出“谁发布、谁观察、观察哪个状态”的场景，可以用 acquire/release 精确表达关系；如果需要更强的全局排序，或团队无法稳定维护配对关系，volatile 可能更容易读懂。

为什么读到 ready 后还要再读 payload？

ready 是状态，不是数据本身。读方通过 getAcquire 取得状态后，后续的普通读取才是在该同步关系之后发生；把状态值当成 payload，或者在 acquire 之前读取 payload，都会改变问题。

只给 payload 用 getAcquire 可以吗？

如果没有一个匹配的 release 写入把数据发布出去，单独对 payload 做 acquire 读取并不能凭空创造发布关系。先找到承载发布关系的状态变量，再决定哪一个访问模式作用于哪一个字段。