反射调用大对象会放大装箱、拷贝和缓存失效三重开销：基本类型强制装箱、参数数组内存搬运、JIT逃逸分析失效致堆分配激增，且缓存粒度不匹配易引发运行时异常。
大对象 + 反射 = 装箱/拷贝/缓存失效三重放大
反射本身不区分对象大小，但处理大对象时，原本被忽略的开销会指数级暴露。核心问题不是“反射慢”，而是反射把 JVM 原本可以优化掉的路径全绕过去了。
基本类型装箱在大对象中被高频触发
当你反射调用一个接收 int、long 或数组参数的方法时，Method.invoke() 强制要求所有参数是 Object 类型。这意味着：哪怕方法签名里写的是 void process(long id, byte[] data)，你传进去的 long 会被自动装箱成 Long，而 byte[] 虽然不用装箱，却可能因反射调用链变长导致 GC 压力陡增。
- 大对象（如 1MB 的
byte[]）本身不装箱，但它的存在会让 JIT 更难做逃逸分析，导致本可栈分配的对象被迫堆分配 - 如果反射调用在循环里（比如批量解析 JSON 对象），每次迭代都新建
Long、String等包装类，GC 频率直接拉满 -
invoke()内部还要把参数数组从Object[]拷贝到内部缓冲区，对大数组就是纯内存搬运
MethodHandle 也无法完全规避大对象瓶颈
MethodHandle 确实比 Method.invoke() 快，因为它跳过了部分安全检查和参数数组封装逻辑。但它依然要走 JNI 层，且无法改变 JVM 对大对象的内存管理策略。
- 用
lookup.findVirtual()获取句柄后，调用mh.invoke(obj, bigArray)仍需把bigArray当作引用传递，JVM 不会为你做零拷贝 - 如果目标方法内部又做了深拷贝（比如
clone()或序列化），反射只是“触发器”，真正耗时在业务逻辑，但调用链越长，定位越困难 - JDK 17+ 的 ZGC/Shenandoah 对大对象回收更友好，但反射调用本身不会让 GC 变快——它只是让 GC 更早被触发
缓存失效在大对象场景下更隐蔽
很多人缓存了 Method，就以为万事大吉。但在大对象处理中，缓存粒度错一点，性能就断崖下跌。
- 用
clazz.getName() + "#"+ methodName当缓存 key？遇到泛型擦除或重载方法时，实际拿到的可能是setPayload(Object)而非setPayload(byte[])，结果运行时抛IllegalArgumentException - 缓存了
Field却没注意字段是否被 JIT 优化为常量（比如private static final byte[] EMPTY = new byte[0]），反射写入会静默失败 - 大对象常伴随复杂嵌套结构（如
List<map object>></map>），用反射遍历每一层时，getDeclaredFields()返回的字段顺序不稳定，缓存的索引可能错位
真正卡住的往往不是反射那几纳秒，而是它让 JVM 失去了对数据生命周期的掌控权——大对象一旦进入反射调用链，就很难再被优化、压缩或复用。别只盯着 invoke() 耗时，先看清楚你传进去的那个 byte[] 或 Map，是不是在反复创建、拷贝、等待 GC。
