methodhandle比反射快的关键在于jvm对其实施更激进的jit内联与去虚拟化优化，且调用时无参数数组封装、无运行时类型擦除与安全检查，配合显式methodtype签名和句柄复用可逼近直接调用性能。
MethodHandle 比反射快的关键在哪
不是因为“底层用了 JNI”或者“绕过了安全检查”——MethodHandle 依然受 Java 安全管理器约束，且调用链路里仍有访问检查。真正快的原因是：JVM 对 MethodHandle 做了更激进的内联与去虚拟化优化，尤其是当它被频繁调用、且目标方法稳定时，HotSpot 会把它当作“准静态调用”处理。而 Method.invoke() 固定走解释执行路径，即使被 JIT 编译，也难消除其通用参数封装（Object[] args）和类型擦除带来的开销。
必须用 Lookup.findVirtual + asType 配合才能发挥性能
直接用 lookup.unreflect(method) 得到的 MethodHandle，若参数/返回类型与实际调用不完全匹配，会在每次调用时触发隐式适配，反而比反射还慢。正确做法是显式绑定签名：
MethodType targetType = MethodType.methodType(String.class, int.class, boolean.class);
MethodHandle mh = lookup.findVirtual(String.class, "substring",
MethodType.methodType(String.class, int.class))
.asType(targetType); // 显式转成你真实要调用的签名
-
asType必须在初始化阶段一次性完成，不能每次调用前都调；否则适配逻辑重复执行，性能归零 - 避免用
asType转换涉及装箱/拆箱或泛型擦除的类型（如int↔Integer），这会引入MethodHandle内部的适配器链 - 如果目标方法是 static，用
findStatic；是构造器，用findConstructor；选错查找方法会导致NoSuchMethodException
缓存 MethodHandle 实例，但别缓存 Lookup
MethodHandle 是线程安全、不可变的，适合全局静态缓存；而 Lookup 实例携带访问权限上下文，缓存它可能引发 IllegalAccessException（尤其在模块化环境下）：
private static final MethodHandle SUBSTRING_MH;
static {
try {
MethodType mt = MethodType.methodType(String.class, int.class);
SUBSTRING_MH = MethodHandles.lookup()
.findVirtual(String.class, "substring", mt)
.asType(MethodType.methodType(String.class, String.class, int.class));
} catch (Throwable t) {
throw new ExceptionInInitializerError(t);
}
}
- 不要在每次调用时 new
Lookup或反复调用lookup()——它本身不重，但反复查方法表有开销 - 模块系统中，若目标类在其他模块，需确保调用方模块对目标包有
opens声明，否则findVirtual直接失败 - 缓存失效场景极少，但一旦类被重定义（如热部署），
MethodHandle不会自动更新，仍指向旧版本方法体
性能差距不到 50%？检查是否踩了“未预热”或“签名不匹配”坑
实测发现多数人达不到宣传中的 50%+ 提升，核心问题集中在两个地方：
- JVM 需要足够多的调用次数（通常 >10000 次）才会对
MethodHandle做深度优化；用 JMH 测的话，@Fork和@Warmup缺一不可 - 反射调用时若用了
setAccessible(true)，其实已经跳过了大部分访问检查，此时MethodHandle的优势会被压缩到 20% 左右；真想拉开差距，得对比“未设 accessible”的反射调用 - 如果被调方法本身很轻（比如只 return 0），那调用机制的占比就高，差异明显；若方法体耗时长（如 IO 或计算），两者差距会迅速收敛到个位数百分比
真正难的是让 MethodHandle 在复杂泛型、桥接方法、默认接口方法等场景下保持类型精确——稍有偏差，JVM 就退回到解释执行模式，所有优化清零。
