热部署时反射缓存导致方法调用错乱，因method等对象绑定旧类字节码；需检查异常日志、类加载器一致性，清空spring/apache/jackson反射缓存，手动缓存应隔离类加载器，禁用jvm反射膨胀可治本。
热部署时方法调用错乱，常不是类没重载，而是反射缓存里的旧 Method、Field 或 Constructor 对象仍被复用——这些对象绑定了老版本类的字节码结构，一旦类被重新加载（如 devtools 触发 restart），它们就指向了已卸载或不一致的类元信息，从而引发 NoSuchMethodException、ClassCastException，甚至静默调用到错误方法。
确认是否是反射缓存导致的问题
先排除其他干扰，聚焦反射层：
- 检查日志中是否出现
java.lang.NoSuchMethodException或IllegalArgumentException: object is not an instance of declaring class，且发生在你刚修改过方法签名（比如加参数、改返回值）之后 - 在出问题的方法调用处加断点，观察
Method.getDeclaringClass()返回的 Class 实例的ClassLoader是否与当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）一致；若不一致，大概率是缓存了上一轮加载的 Class 的反射对象 - 若项目用了 Apache BeanUtils、Spring BeanUtils.copyProperties 或 Jackson 的反射访问器，它们内部普遍自带反射缓存（如
BeanUtilsBean.getInstance().getPropertyUtils().getProperty(...)），这类缓存默认不感知热重启
清理或绕过第三方框架的反射缓存
主流工具库的反射缓存大多可主动清空或禁用：
-
Spring BeanUtils：它底层依赖
org.springframework.beans.CachedIntrospectionResults。调用CachedIntrospectionResults.clearCache()即可清空全部缓存（建议在 devtools 的RestartEndpoint回调或自定义ContextRefreshedEvent监听器中执行） -
Apache Commons BeanUtils：调用
PropertyUtilsBean.resetBeanIntrospector()和ConvertUtilsBean.deregister()，再新建实例替换全局单例（注意线程安全） -
Jackson（2.12+）：启用
MapperFeature.USE_STATIC_TYPING可减少反射缓存依赖；或设置ObjectMapper.setConfig(objectMapper.getSerializationConfig().withFeatures(SerializationFeature.USE_STATIC_TYPING))
自己写的反射缓存必须支持热感知
如果你在工具类中手动用 ConcurrentHashMap 缓存了 Method，需加入类加载器维度隔离：
- 缓存 key 不仅含类名+方法名+参数类型，还应包含
clazz.getClassLoader()的哈希或弱引用标识 - 监听 Spring Boot 的
ContextClosedEvent或RestartEventData，触发缓存按类加载器批量清除（避免全量清空影响性能） - 更稳妥的做法：不缓存
Method对象本身，改为缓存方法签名字符串 + 调用逻辑（如用MethodHandle替代Method.invoke），因为MethodHandle在类重定义后会自动失效并重建
禁用 JVM 反射膨胀机制（治本之策）
高频反射调用会触发 JVM 自动生成 GeneratedMethodAccessor 类，这些类驻留在 Metaspace 中，若未及时卸载，新旧类共存时极易让反射缓存“指错方向”：
- 启动参数加入
-Dsun.reflect.noInflation=true，强制所有反射调用走统一动态生成路径，避免第 16 次调用才生成加速器带来的版本跳跃 - 配合
-XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrent，提升 Metaspace GC 效率，确保旧类及其反射类能被及时回收 - 验证是否生效：加
-XX:+TraceClassLoading启动，观察日志中是否不再出现sun.reflect.GeneratedMethodAccessor\d+
