Java VarHandle compareAndExchangeAcquire 如何写无锁状态更新：内存语义、旧值判断与失败分支

线上任务只允许一个线程完成“待处理”到“已接管”的切换时，最容易写错的不是原子性，而是把“写成功”和“读到了什么”混成一个布尔值。Java 的 VarHandle.compareAndExchangeAcquire 会返回实际观察到的旧值：旧值等于期望值，才完成替换；旧值不同，则保留并发线程已经写入的状态。用这个返回值分支，既能避免额外读取，也能把竞争结果记录清楚。

compareAndExchangeAcquire 适合“按期望状态尝试推进一次”的场景：把返回的 witness 值与 expectedValue 比较，等于期望值就是当前线程切换成功，不等于则说明状态已被别人先改变。

状态切换为什么要保留 witness 值

假设一个任务有两个状态：0 表示待处理，1 表示已经接管。两个线程同时尝试接管时，普通的“先读再写”会产生竞态：线程 A 和线程 B 都可能先读到 0，随后都把状态写成 1，但业务日志无法说明谁真正赢得了这次切换。

compareAndExchangeAcquire 把比较、条件写入和旧值返回合并为一次访问。它的调用形状是“位置、expectedValue、newValue”，返回值叫 witness；成功时 witness 等于 expectedValue，失败时 witness 是另一个线程先写入的实际值。

用 VarHandle 写出只接管一次的最小代码

下面的 state 是真实共享字段，STATE 负责定位它。tryClaim 不把失败伪装成异常，而是返回观察到的状态，调用方可以据此区分“已接管”和“已被别人接管”。

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

final class TaskGate {
    private static int state;
    private static final VarHandle STATE;

    static {
        try {
            STATE = MethodHandles.lookup()
                    .findStaticVarHandle(TaskGate.class, "state", int.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    static boolean tryClaim() {
        int witness = (int) STATE.compareAndExchangeAcquire(0, 1);
        return witness == 0;
    }
}

这里的控制流只有一条关键判断：witness == 0。第一次调用把 state 从 0 写成 1 并返回 true；后续调用观察到 1，不会再次写入，返回 false。compareAndExchangeAcquire 的 acquire 读取语义适合在成功观察到状态后读取先前发布的数据，但它不会替你设计任务的重试和释放协议。

把成功与竞争失败分成两个可观察结果

为了验证并发行为，可以保留一次尝试的结果，而不是只打印一个“成功/失败”。下面的 ClaimResult 记录 witness 值；当多个线程同时进入 tryClaimWithWitness 时，最多一个线程得到 witness=0，其他线程得到已经存在的 witness=1。

record ClaimResult(boolean claimed, int witness) {}

static ClaimResult tryClaimWithWitness() {
    int witness = (int) STATE.compareAndExchangeAcquire(0, 1);
    return new ClaimResult(witness == 0, witness);
}

这个结果还原了真实调用链：调用方进入 tryClaimWithWitness，STATE 执行一次原子访问，返回 witness，最后由 ClaimResult 暴露成功或竞争状态。不要把 witness=1 理解为异常；它只是说明期望值已经不成立。

Acquire 语义、释放动作和重试边界

compareAndExchangeAcquire 不是“更快的 compareAndSet”这种简单替换。它在读取当前值时使用 acquire 语义，成功时对新值执行普通 set 语义；如果后续代码需要把一批数据发布给其他线程，必须从整体发布协议判断是否需要更强的 release 或 volatile 访问。

另外，示例没有把 state 从 1 改回 0。这是刻意留下的业务边界：一次性接管、租约接管和可重入锁的释放规则完全不同。若任务允许失败后重试，应另行定义谁负责释放，以及释放是否必须检查拥有者标识，不能直接追加一条普通写入。

三组测试足以发现常见误用

• 首次调用：断言 tryClaim() 为 true，再检查后续调用为 false。
• 并发调用：用多个线程同时调用 tryClaimWithWitness()，统计 witness=0 的结果只能有一个。
• 重复调用：确认状态已经是 1 时，失败分支不执行重复初始化，也不把竞争当成系统异常。

测试结束后要隔离静态字段状态，否则前一组用例留下的 state=1 会让“首次接管”用例失去意义。生产代码则应把状态初始化和释放策略写在同一个生命周期设计里。

常见问题

compareAndExchangeAcquire 返回的是成功标记吗？

不是。它返回 witness 旧值；把 witness 与 expectedValue 比较，才能得到本次是否替换成功。

为什么不用 compareAndSet？

如果只需要布尔结果，compareAndSet 更直接；需要知道竞争者留下了什么状态时，compare-and-exchange 的 witness 更有信息量。

失败后应该立即重试吗？

不应该默认重试。先判断状态是否允许当前调用者继续，任务接管、租约续期和一次性初始化的失败处理不同。

小结

写无锁状态更新时，先明确 expectedValue 和 newValue，再利用 witness 值做分支。TaskGate 的最小规则是 0 只允许被一次性替换为 1；真正复杂的部分在状态生命周期、可见性语义和失败后的责任划分。