Java反射调用Method.invoke本身不直接产生大量临时对象，但参数数组重复创建、Method未缓存、异常包装、泛型类型动态解析等配套操作会引发高频对象分配，加剧GC压力。
Java反射调用 Method.invoke 本身不会直接产生大量临时对象，但实际使用中常因配套操作（如参数包装、类型转换、异常处理、反射缓存缺失等）引发高频对象分配，进而加剧GC压力。关键在于识别哪些环节在“悄悄”创建对象，而非单纯归咎于invoke本身。
参数数组的重复创建是常见源头
每次调用 method.invoke(obj, arg1, arg2) 若使用可变参数语法，JVM会自动装箱并生成一个 Object[] 数组。即使只传一个基本类型参数（如 int），也会触发 Integer.valueOf() 装箱 + 新建长度为1的数组。
- 避免写法：
method.invoke(obj, 123)→ 每次都新建Object[]{new Integer(123)} - 推荐写法：预分配并复用参数数组，例如
Object[] args = new Object[1]; args[0] = 123;，后续复用该数组（注意线程安全） - 对固定参数个数的方法，可封装一层静态工具方法，内部复用数组，避免上层反复构造
反射元数据未缓存导致重复解析
频繁调用 clazz.getMethod("xxx") 或 clazz.getDeclaredMethod("xxx") 会产生 Method 实例，而 Method 对象内部持有类信息、签名、注解等引用，且部分 JDK 实现中其 toString()、getAnnotations() 等方法会动态构建字符串或集合。
- 务必缓存
Method对象（如用ConcurrentHashMap），按类+方法名+参数类型为 key - 避免在循环内或高频路径中重复查找方法；缓存后调用
setAccessible(true)也只需一次 - 注意：缓存的
Method是线程安全的，可跨线程共享
异常堆栈和包装器开销容易被忽略
当反射调用目标方法抛出异常时，Method.invoke 会将原始异常包装为 InvocationTargetException，并填充完整堆栈。若目标方法本身异常率高（如校验失败、业务异常频发），就会持续创建异常对象及其栈帧数组，这类对象生命周期短、分配快、GC压力明显。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 检查业务逻辑：是否在反射调用中高频抛出非必要异常？考虑用返回码或 Optional 替代部分异常流
- 避免在
catch (InvocationTargetException e)后调用e.printStackTrace()或e.getStackTrace()—— 这些操作会触发栈帧解析与数组复制 - 如需日志，优先记录
e.getCause()的简要信息，而非完整包装异常
泛型擦除与类型检查带来的隐式对象分配
当反射调用涉及泛型类型（如 List<String>）且未正确处理类型擦除时，某些框架（如 Jackson、Spring 类型转换器）可能在反射上下文中动态构造 Type 实现（如 ParameterizedTypeImpl）、Class<?> 数组或临时 Map 存储类型变量映射。
- 若使用 Spring 的
ResolvableType或 Jackson 的TypeFactory，确认是否在每次反射调用中重建类型信息 - 对固定签名的方法，提前解析好目标类型并缓存（如
resolvableType.forMethodReturnType(method)结果） - 避免在 invoke 前反复调用
method.getGenericReturnType()—— 某些 JDK 版本中该方法会惰性构建内部结构
不复杂但容易忽略：真正造成 GC 压力的，往往不是 invoke 这一行代码，而是它前后那几行看似无害的参数准备、异常处理和元数据获取。定位时建议用 JFR 或 Async-Profiler 抓取分配热点，重点关注 Object[]、Integer、InvocationTargetException 和各类 Type 实现类的分配位置。
