VarHandle 可安全替代 Unsafe 的大部分原子操作，但受限于字段可定位性、访问权限和内存语义；需用 privateLookupIn 获取 lookup，字段类型须为原始类型，final 字段禁用 compareAndSet，数组操作须用 ofArray()，访问模式需成对使用，且不支持堆外内存与任意地址访问。
VarHandle 可以安全替代 Unsafe 的大部分原子操作，但不是所有场景都能直接替换——关键在于字段可定位性、访问权限和内存语义是否匹配。
VarHandle 替代 Unsafe.compareAndSwapInt 的正确写法
Unsafe 的 compareAndSwapInt 常用于对象字段的 CAS 更新，但需手动计算字段偏移量，极易出错且跨平台不兼容。VarHandle 把这个过程交给 JVM，在编译期或运行时解析字段位置，更安全。
常见错误现象：UnsupportedOperationException 抛在 lookup.findVarHandle() 调用时，通常因为字段是 private 但没走 privateLookupIn；或字段类型不匹配（比如传 Integer.class 而非 int.class）。
- 必须用
MethodHandles.privateLookupIn(Counter.class, MethodHandles.lookup())获取 lookup 实例，再调用findVarHandle() - 字段类型必须是原始类型（
int.class、long.class），不能是包装类（Integer.class） -
final字段允许getVolatile()，但禁止compareAndSet()—— 这点和 Unsafe 一致，但 VarHandle 会提前报错，而不是静默失败 - 示例：
class Counter {
int value;
}
// 正确构造
MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(Counter.class, MethodHandles.lookup());
VarHandle vh = lookup.findVarHandle(Counter.class, "value", int.class);
// 使用
Counter c = new Counter();
vh.compareAndSet(c, 0, 1); // ✅
数组元素的原子更新必须用 VarHandle.ofArray()
Unsafe 支持对任意数组地址执行 compareAndSwapInt(array, offset, ...)，但 offset 计算依赖 arrayBaseOffset 和 arrayIndexScale，极易溢出或越界。VarHandle 强制你用类型安全的方式处理数组。
使用场景：实现无锁 RingBuffer、并发计数桶（count bucket）、分段哈希表等。
- 不能对
int[]用ofField()—— 会抛IllegalArgumentException - 必须用
VarHandle.ofArray(int[].class)，返回的 VarHandle 只接受int[]和int索引参数 - 支持
getAndAdd(int[] array, int index, int delta)等原子操作，语义与AtomicIntegerArray一致，但无包装开销 - 注意：数组长度检查由 JVM 在调用时完成，越界仍抛
ArrayIndexOutOfBoundsException
volatile 读写和内存屏障语义要按需选型
Unsafe 提供 putOrderedInt、putVolatileInt 等方法，对应不同内存排序强度。VarHandle 把这些抽象为访问模式（access modes），但命名更直白，也更严格。
容易踩的坑：setRelease() 和 getAcquire() 不是“更强的 volatile”，而是配合使用的成对语义；单独用 setRelease() 写入后，若另一线程只用普通 get() 读，不能保证可见性。
-
setVolatile()≈Unsafe.putVolatileInt()：全屏障，强可见性 -
setOpaque()≈Unsafe.putOrderedInt()：仅禁止重排序，不刷新缓存，性能更高 -
setRelease()+getAcquire()构成“发布-获取”同步对，适合生产者-消费者模型中的状态发布 - ARM64 或 RISC-V 平台下，
weakCompareAndSetPlain()可能假失败（spurious failure），而compareAndSet()保证强一致性 —— 别只图快就默认用 weak 版本
为什么不能完全抛弃 Unsafe？VarHandle 的能力边界在哪
VarHandle 解决了 Unsafe 最危险的三类问题：字段偏移计算、堆外内存裸指针、绕过构造器实例化。但它不提供以下能力，这些仍是 Unsafe（或新 API 如 Foreign Memory Access API）的职责范围：
- 无法访问任意内存地址 —— VarHandle 只支持对象字段、静态字段、数组元素这三类可静态描述的目标
- 不支持
allocateMemory()/freeMemory()，堆外内存分配仍需MemorySegment或Unsafe - 无法
putObject()到任意地址，也不能像Unsafe.copyMemory()那样做块拷贝 - 不支持动态生成对象（
allocateInstance()），单例破坏风险仍需靠设计规避
真正需要警惕的是：把 VarHandle 当作“语法糖”来用，忽略其初始化开销。每个 findVarHandle() 调用都涉及反射权限检查和 JVM 元数据查找，应作为 static final 缓存，而非每次操作都重建。
