VarHandle 是官方明确设计的 Unsafe 替代方案，非封装而是从内存模型、类型系统和模块安全三方面重建语义；迁移需校验字段声明合规性、模块开放声明及类型严格匹配，并缓存句柄、区分静态/实例/数组构造方式，正确选用 weakCompareAndSet 或 compareAndSet。
VarHandle 不是对 Unsafe 的“封装”，而是官方明确设计的替代方案——它不复用 Unsafe 底层逻辑，也不兼容其调用方式，而是从内存模型、类型系统和模块安全三方面重建原子字段操作语义。生产环境迁移不是简单替换方法名，而是重构访问契约。
迁移前必须确认的三项前提
很多团队在 JDK 17+ 升级后遇到 IllegalAccessException 或 UnsupportedOperationException，根源常是未校验这三点：
-
字段声明合规性：被操作字段必须是
volatile，或所在类为final（JDK 14+ 放宽限制，但非 volatile 非 final 字段的 CAS 仍会静默退化） -
模块开放声明：若字段为
private，目标类所在模块必须在 JVM 启动时添加--add-opens java.base/java.lang=ALL-UNNAMED（或对应模块名），否则privateLookupIn会失败 -
类型严格匹配：
findVarHandle(Counter.class, "count", int.class)中的int.class不能写成Integer.class，原始类型与包装类不可互换
实例字段与静态字段的构造差异
错误地复用同一 VarHandle 实例处理静态/实例字段，会导致 IllegalArgumentException 或行为异常：
-
静态字段：用
MethodHandles.lookup().findStaticVarHandle(Owner.class, "FIELD_NAME", Type.class)，句柄调用时第一个参数传null -
实例字段：用
MethodHandles.privateLookupIn(Owner.class, MethodHandles.lookup()).findVarHandle(...)，调用时第一个参数必须是具体对象实例 -
禁止混用：对静态字段句柄传入非
null实例，或对实例字段句柄传null，均抛NullPointerException
CAS 操作选型：weakCompareAndSet vs compareAndSet
二者不是性能高低之分，而是语义边界问题。选错会导致状态丢失或死循环：
-
weakCompareAndSet：允许“假失败”（spurious failure），适合自旋重试场景（如无锁栈 push），x86 上通常编译为单条
cmpxchg指令，无额外内存屏障 - compareAndSet：强顺序语义，等价于 volatile 写 + CAS，在 ARM 等弱内存序平台插入显式屏障，适合状态机跃迁（如从 RUNNING → STOPPED）
-
关键提醒：跨线程可见性依赖
getVolatile/setVolatile配对，不能用普通get/set替代
性能与生命周期管理要点
VarHandle 构造开销显著高于调用开销，高频场景下重复创建会拖垮吞吐量：
-
必须缓存：静态字段句柄声明为
private static final VarHandle VH = ...；实例字段句柄建议按类缓存在ConcurrentHashMap<Class<?>, VarHandle>中 -
禁止反射查找热路径：避免在循环内、高并发 getter/setter 中动态调用
findVarHandle，实测 JDK 21+ 下比缓存慢 20–50 倍 -
数组操作走专用入口：不要试图用字段句柄操作数组元素，必须用
VarHandle.ofArray(int[].class)获取数组句柄，否则抛IllegalArgumentException
迁移不是代码层面的机械替换，而是对内存模型理解的升级。VarHandle 把原本隐藏在 Unsafe 偏移量里的语义，显式暴露为类型、权限、访问模式三个可验证维度。只要守住字段声明、模块开放、句柄复用这三条线，就能把风险从“JVM 崩溃”降到“编译时报错”或“运行时明确异常”。
