反射效率低的根本原因是绕过编译期调用路径，将安全检查、方法查找、参数解包与JNI切换四步开销拖至运行时；Inflation机制在调用达15次后动态生成GeneratedMethodAccessor类，以字节码硬编码替代Native调用，使后续调用免去查找、检查与边界切换，大幅提升性能。
直接使用反射效率低，根本原因在于它绕过了编译期确定的调用路径，把大量本该静态完成的工作拖到运行时去做；而 Inflation 膨胀机制，是 JVM 在发现某个反射方法被频繁调用后，主动用字节码生成替代 Native 调用，从而大幅降低后续开销的“懒优化”策略。
反射慢在哪儿：四步额外开销
直接调用 obj.method() 通常只需一条 invokevirtual 指令，JIT 还能内联优化。反射调用 method.invoke(obj) 却要走完整四步链路：
-
安全检查：每次调用都触发
getCallerClass()（Native 方法），再逐层校验访问权限，即使已调用setAccessible(true)，初始阶段仍需运行时确认； - 方法查找：根据方法名和参数类型，在类的元数据中做字符串匹配与签名比对，无法复用编译期解析结果；
-
参数解包与类型转换：将
Object[]参数逐一拆解、装箱/拆箱、按目标签名强转，过程动态且无类型推导； -
JNI 边界切换：初始调用最终落入
invoke0()这个 Native 方法，每次都要跨越 Java/Native 边界，带来寄存器保存、栈帧切换、上下文重建等固定开销。
Inflation 膨胀机制怎么起作用
这不是一上来就生成字节码，而是“先忍15次，再动手优化”。默认阈值为 15 次（可通过 -Dsun.reflect.inflationThreshold= 修改），触发后 JVM 动态生成一个专用的 GeneratedMethodAccessorX 类：
- 这个类是为当前
Method对象量身定制的，硬编码了目标方法签名、参数顺序、返回类型； - 它的
invoke()方法直接用字节码发出invokevirtual或invokespecial，跳过所有查找与检查逻辑； -
Method内部持有的MethodAccessor引用被替换，后续所有调用都走这个纯 Java 的存根方法，不再进 Native 层。
为什么膨胀后就快了
生成的存根方法本质是“模拟了编译期调用”，让 JIT 编译器重新获得优化机会：
立即学习“Java免费学习笔记（深入）”；
- 调用路径固定，JIT 可以内联目标方法，消除方法调用开销；
- 参数解包逻辑变成确定性字节码，避免运行时类型判断和反射式转换；
- 安全检查结果被固化（如
setAccessible(true)已生效），无需重复验证； - 完全脱离 JNI，规避了跨语言边界带来的不可预测延迟和 GC 干扰。
实际影响与注意事项
膨胀不是万能加速器，它只对**稳定、高频、复用同一 Method 实例**的场景有效：
- 如果每次反射都新建
Method对象（比如没缓存），膨胀不会复用，每次都要重走 15 次冷启动； - 首次调用仍慢，预热不足时性能波动明显，压测或启动初期尤其敏感；
- 生成的
GeneratedMethodAccessorX类会常驻元空间，过多反射入口可能引发元空间 OOM； - JDK 9+ 中部分场景已转向
MethodHandle，其内在机制更接近直接调用，但原理上仍存在类似“链接”与“适配”的开销。
