java反射method.invoke()从jdk7起采用渐进优化：前15次走jni慢路径，之后动态生成字节码适配器（如generatedmethodaccessorn）实现快路径，跳过安全检查与参数包装，提升性能。
Java 反射中的 Method.invoke() 并非始终以统一方式执行。从 JDK 7 开始（确切说是 HotSpot VM 的优化策略），JVM 对频繁调用的反射方法实施了一种渐进式优化机制：在调用约 15 次后，会将原本通过本地方法（JNI）实现的慢速反射路径，切换为动态生成的字节码（即“inflated”版本），从而显著提升后续调用性能。
为什么需要“15次”这个阈值？
这个数字不是硬编码的魔法常量，而是 HotSpot 中 ReflectionFactory.inflationThreshold 的默认值（可通过 JVM 参数 -Dsun.reflect.inflationThreshold=N 修改）。它的设计目标是平衡启动开销与长期性能：
- 前几次调用走 JNI 路径，开销大但无需生成类、无类加载压力，适合偶发反射场景
- 当调用频次表明该反射操作具有“热点”特征时，JVM 主动触发膨胀（inflation），生成一个专用的、类型安全的字节码适配器类（如
ReflectAccess$1类） - 该生成类绕过大部分反射安全检查和参数包装，直接调用目标方法，接近普通 invokevirtual 的速度
膨胀后的字节码做了什么？
膨胀并非生成目标方法本身的副本，而是生成一个“桥接器”类，其核心逻辑包括：
- 对传入的
Object[] args数组进行静态类型校验与解包（例如把Integer拆箱为int） - 直接调用目标方法（如
targetObj.targetMethod(arg0, arg1, ...)），不经过MethodAccessor抽象层 - 将返回值自动装箱或处理异常，再封装为
Object返回给invoke()调用方 - 整个过程跳过了
SecurityManager检查（若已启用）、访问控制验证（前提是首次调用时已通过）等重复开销
如何验证是否发生膨胀？
可通过反射观察 Method 内部的 MethodAccessor 实例变化：
- 初始阶段：
method.getAccessible(true); method.invoke(...)多次后，method.getDeclaringClass().getDeclaredField("methodAccessor")（需设为可访问）指向NativeMethodAccessorImpl - 第 15 次左右调用后，该字段变为
DelegatingMethodAccessorImpl，其 delegate 指向GeneratedMethodAccessorN（N 为序号） - 也可启用 JVM 参数
-XX:+TraceClassLoading，观察日志中是否出现类似java.lang.reflect.GeneratedMethodAccessor1的类加载记录
实际影响与注意事项
这一机制对开发者透明，但理解它有助于合理使用反射：
- 避免在热循环中“重置”反射对象（如反复
getMethod()），因为每次新Method实例都需重新计数、重新膨胀 - 若确定某反射调用必为高频，可在应用初始化阶段主动“预热”（调用 15+ 次），使后续业务调用直接命中快路径
- 注意：JDK 9+ 引入模块系统后，跨模块反射默认受限；即使膨胀成功，若未正确打开模块（
--add-opens），仍会在运行时抛出IllegalAccessException - 现代框架（如 Spring、Jackson）普遍缓存
Method和预热 accessor，正是利用了该机制
