所谓“方法引用被重置”实为Method对象反复触发膨胀生成新GeneratedMethodAccessor，根源在于其绑定的MethodAccessor与调用方类加载器强耦合，加载器不可达时JVM被迫重建accessor。
这不是“方法引用被重置”，而是 JVM 在反射调用中对 Method 对象与底层 MethodAccessor 实例的生命周期管理机制被误读——所谓“优化重置”，实为 同一 Method 对象在不同调用上下文中触发了多次膨胀，生成多个不复用的 GeneratedMethodAccessor 类。根本原因在于：Method 对象虽可复用，但其绑定的 MethodAccessor 是懒加载、单例且与调用者类加载器强耦合，一旦调用方类加载器不可达或被回收，JVM 无法安全卸载其关联的 GeneratedMethodAccessor，后续新请求只能重新膨胀。
为什么“方法引用”看似被重置？
开发者常把 Method method = clazz.getDeclaredMethod("xxx") 当作“稳定引用”，误以为缓存它就能一劳永逸。但实际：
-
Method本身只是元数据容器，真正执行的是它内部持有的MethodAccessor实例 - 每个
MethodAccessor（如GeneratedMethodAccessor42）由sun.reflect.DelegatingClassLoader加载，该类加载器是匿名的、无强引用的，且与首次调用它的线程/类加载器环境绑定 - 若原调用方（如某个 Spring Bean）被销毁、类加载器被回收，其关联的
DelegatingClassLoader进入不可达状态 → 后续再通过同一Method对象调用时，JVM 检测到 accessor 已失效，会丢弃旧实例、新建一个全新的 accessor，再次触发膨胀 - 结果就是：同一个
Method变量，在不同生命周期阶段反复生成新GeneratedMethodAccessor，看起来像“优化被重置”
如何确认是否发生 accessor 重建？
不能只看 Method 对象哈希值是否相同，要穿透到 accessor 层级验证：
- 用 Arthas 执行：
ognl '@java.lang.Class@forName("com.example.Target").getDeclaredMethod("doWork").getMethodAccessor()'，观察返回对象类名是否随时间变化（如从GeneratedMethodAccessor102变成GeneratedMethodAccessor215） - 结合
jmap -clstats <pid>，对比两次快照中sun.reflect.DelegatingClassLoader实例数是否持续增长 - 开启
-XX:+TraceClassLoading，搜索日志中是否重复出现sun.reflect.GeneratedMethodAccessor\d+的加载记录，且序号不断递增
高频场景下“重置”的典型诱因
以下情况极易导致 accessor 被丢弃并重建：
- Spring Bean 多例（prototype）或作用域动态切换：每次创建新 Bean 实例，反射调用可能走不同类加载路径，触发新 accessor
- OSGi 或热部署容器（如 Tomcat reload）：WebAppClassLoader 卸载后，所有由它间接触发的 DelegatingClassLoader 全部失效
- 泛化调用网关（如 Dubbo 泛化调用）：每次请求携带不同服务接口类，即使方法签名一致，JVM 也视为全新调用组合
- 自定义 ClassLoader 频繁创建/销毁：如规则引擎按租户隔离加载策略类，每个租户 ClassLoader 触发独立膨胀链
真正有效的应对策略
目标不是“防止重置”，而是切断 accessor 与临时类加载器的绑定关系：
-
强制禁用膨胀：加
-Dsun.reflect.noInflation=true，让所有反射统一走 JIT 友好的动态生成路径，不再依赖 DelegatingClassLoader，避免因加载器失效导致重建 -
升级到 MethodHandle 并显式保持强引用：用
MethodHandles.lookup().unreflect(method)获取MethodHandle，它不依赖类加载器，可安全缓存至静态 Map 中复用 -
对高频固定方法，改用编译期绑定：如 Jackson 使用
@JsonCreator+@JsonProperty替代默认反射构造；MyBatis 开启useColumnLabel=false减少字段名解析开销 -
避免缓存 Method 对象本身：改为缓存
MethodHandle或预编译的Function<Object, Object>（通过 LambdaMetafactory），绕过 MethodAccessor 生命周期问题
