MethodHandle比反射快的关键在于JVM对其调用链的深度内联与去虚化优化，复用缓存句柄时可编译为接近直接调用的机器码；而反射每次调用均需权限检查、参数数组包装、异常包装三层开销。
MethodHandle 比反射快的关键在哪
不是因为“底层用了 JNI”或者“绕过了安全检查”——MethodHandle 依然受 Java 安全管理器约束，私有成员访问仍需 setAccessible(true)。真正提速的核心是：JVM 对 MethodHandle 的调用链做了深度内联与去虚化优化，尤其在多次复用同一个 MethodHandle 实例时，HotSpot 能把它编译成接近直接调用的机器码。而 Method.invoke() 每次都走通用分发逻辑，带类型擦除、参数数组包装、异常包装三层开销。
如何正确创建并缓存 MethodHandle 访问私有字段
直接用 privateLookupIn 是必须的，否则无法获取私有成员的 MethodHandle；且必须缓存结果，反复调用 lookup.findGetter() 不仅慢，还可能触发重复权限检查。
- 使用
MethodHandles.privateLookupIn(TargetClass.class, MethodHandles.lookup())获取具备私有访问能力的 lookup 实例 - 用
lookup.findGetter(TargetClass.class, "fieldName", FieldType.class)获取字段读取句柄，写入则用findSetter - 务必把返回的
MethodHandle存为static final字段或 ConcurrentHashMap 缓存，避免每次重建 - 注意：字段类型必须精确匹配，
int和Integer不能混用，否则抛WrongMethodTypeException
示例：
private static final MethodHandle NAME_GETTER;
static {
try {
MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(User.class, MethodHandles.lookup());
NAME_GETTER = lookup.findGetter(User.class, "name", String.class);
} catch (Throwable e) {
throw new ExceptionInInitializerError(e);
}
}
调用私有方法时怎么避免 ClassCastException
常见错误是忽略方法签名中的隐式参数（如静态方法无 receiver，实例方法第一个参数必须是 target 对象）。MethodHandle 的类型系统比反射严格得多，类型不匹配会在调用时直接抛 WrongMethodTypeException，而不是运行时转型失败。
- 实例方法：调用前确保
invokeExact(target, arg1, arg2)中target类型与声明类一致 - 若目标方法参数含泛型擦除类型（如
List），MethodHandle只认List.class，无需特殊处理 - 需要适配参数顺序或类型时，用
MethodHandles.dropArguments()或MethodHandles.explicitCastArguments()，但会轻微影响性能，慎用 - 避免在循环里反复调用
invokeExact前做类型判断——提前用asType()一次性转换好句柄类型
为什么缓存 MethodHandle 后仍比反射慢？可能是这几个点
实测发现缓存后性能只提升 20% 甚至更差，大概率踩了这些坑：
- 误用
invoke()而非invokeExact()：前者会尝试自动适配参数和返回值类型，开销接近反射；必须保证调用签名与MethodHandle.type()完全一致才用invokeExact - 缓存了未绑定的句柄却当成已绑定用：比如对实例方法没调用
bindTo(instance)，导致每次都要传 target，增加一个参数压栈成本 - 在 LambdaMetafactory 场景下混用：如果最终目标是生成函数式接口实现，直接用
LambdaMetafactory.metafactory()比手撸MethodHandle更高效，别为了“用而用” - JDK 版本影响大：JDK 9+ 对
MethodHandle内联优化显著增强，JDK 8 下提升有限，实测数据需按实际 JDK 校准
真正发挥 50%+ 性能优势的前提，是固定调用模式 + 热点代码 + 正确缓存 + invokeExact 直接命中。一旦涉及动态类型推导或频繁重建句柄，优势就消失了。
