compareAndExchange 总返回当前值（无论是否成功），而 compareAndSet 仅返回布尔结果；前者支持响应式反馈（如获取实际版本号），后者仅指示成功与否。
compareAndExchange 和 compareAndSet 语义差异在哪
compareAndExchange 不是“加强版 compareAndSet”，而是语义上更中立的原子读-改-写操作：它总返回当前值（无论是否成功交换），而 compareAndSet 只返回布尔结果。这意味着你能立刻知道“为什么没换成功”——比如因为值已被其他线程改过，或根本没变过。
这在需要响应性反馈的场景里很关键：比如实现带版本号的乐观锁时，你不仅要知道更新失败，还要拿到当前版本号来决定是重试、降级还是报错。
常见错误是把它当 compareAndSet 用却忽略返回值：
handle.compareAndExchange(obj, expected, desired); // ❌ 忽略返回值，等于白调
正确做法是显式检查返回值是否等于
expected，而不是依赖布尔逻辑。
如何用 VarHandle 实现 acquire-release 语义的 CAS
Java 的 VarHandle 允许为每次操作指定内存顺序，而 compareAndExchange 支持四种组合：Acquire、Release、AcquireRelease、SequentiallyConsistent。默认是 SequentiallyConsistent，性能开销最大；但如果你只关心“写后读可见”或“读后写不重排”，可以降级。
-
compareAndExchangeAcquire：保证后续读操作不会被重排到该操作之前
-
compareAndExchangeRelease：保证前面的写操作不会被重排到该操作之后
- 混合使用时（如先
Acquire 读状态，再 Release 更新），能比全序模型减少 fence 指令，提升吞吐
compareAndExchangeAcquire：保证后续读操作不会被重排到该操作之前compareAndExchangeRelease：保证前面的写操作不会被重排到该操作之后Acquire 读状态，再 Release 更新），能比全序模型减少 fence 指令，提升吞吐注意：这些方法不是重载，而是独立方法名——不存在“传参数选语义”的方式。用错方法名会导致语义不符合预期，且编译器不会警告。
compareAndExchange 在非基本类型字段上的限制
VarHandle 的 compareAndExchange 对引用类型字段（Object）完全支持，但对数组元素或嵌套字段（如 obj.field.subfield）需额外构造 handle。更关键的是：它**不支持对 long/double 字段在 32 位 JVM 上的原子操作**——虽然现代 JDK 基本都跑在 64 位上，但若目标环境未明确，仍可能触发 IllegalStateException。
典型踩坑点：
- 用
static final VarHandle VH_LONG = MethodHandles.privateLookupIn(...).findVarHandle(...)构造 handle 时，没校验VH_LONG.isAccessModeSupported(VarHandle.AccessMode.COMPARE_AND_EXCHANGE) - 在 record 或 sealed class 的 final 字段上尝试
compareAndExchange——会直接抛UnsupportedOperationException - 对 volatile 字段同时用
synchronized和compareAndExchange，造成语义冗余甚至死锁风险
和 Unsafe.compareAndSwapXxx 相比，实际性能差多少
VarHandle.compareAndExchange 在 HotSpot 上最终也编译为相同汇编指令（如 x86 的 cmpxchg），所以单次操作延迟几乎一致。但差异出现在 JIT 优化层面：
- 反射式创建的
VarHandle（如通过 MethodHandles.lookup().findVarHandle(...)）会有首次调用开销，后续被内联后无差别
- 静态常量
VarHandle（static final）可被完全内联，性能与 Unsafe 持平
-
Unsafe.compareAndSwapInt 等方法在 JDK 9+ 已标记为 @Deprecated(forRemoval = true)，且部分 JVM（如 GraalVM Native Image）根本不支持
VarHandle（如通过 MethodHandles.lookup().findVarHandle(...)）会有首次调用开销，后续被内联后无差别VarHandle（static final）可被完全内联，性能与 Unsafe 持平Unsafe.compareAndSwapInt 等方法在 JDK 9+ 已标记为 @Deprecated(forRemoval = true)，且部分 JVM（如 GraalVM Native Image）根本不支持真正影响性能的不是方法本身，而是你是否让 JIT 看懂你的模式：比如把 compareAndExchange 写在循环里却不加 final 或稳定类型提示，可能导致去优化。
AcquireRelease 覆盖大多数状态机跃迁场景，过度使用 SequentiallyConsistent 会悄悄拖慢吞吐。 
