MethodHandle 是 JVM 底层调用机制，非反射替代品，而是直接映射 invokedynamic 的轻量级调用抽象，具备零开销热执行但需严格类型匹配、无动态寻址能力。
MethodHandle 是什么：不是反射的替代品，而是 JVM 的底层调用机制
它不是 Java 语言层面的语法糖，而是 java.lang.invoke 包提供的、直接映射到 JVM 底层 invokedynamic 指令的轻量级调用抽象。你可以把它理解为“可编程的字节码调用桩”——不经过反射的权限检查、方法解析缓存、包装对象等开销，但也不自带反射那种动态字符串寻址能力。
常见错误现象：MethodHandle 一旦绑定目标方法（比如通过 Lookup.findVirtual），就不能像 Method.invoke 那样传入任意对象实例；它对参数类型和数量极其严格，类型不匹配会直接抛 WrongMethodTypeException，而不是运行时转型失败。
- 使用场景：高频调用动态确定的方法（如 JSON 反序列化字段 setter、DSL 执行引擎）、需要绕过反射安全检查但又不想写字节码的场景
- 性能影响：冷启动略慢（首次解析 method type），但热执行比反射快 3–5 倍；无同步锁、无
AccessibleObject.setAccessible(true)开销 - 灵活性代价：没有
getDeclaredMethods()这类枚举能力，必须提前知道方法签名；不能跨模块访问 non-public 方法（除非Lookup有对应权限）
反射 vs MethodHandle：性能差异主要在哪儿
关键不在“调用本身”，而在“每次调用前的准备动作”。反射每次 Method.invoke 都要查缓存、做 access check、装箱/拆箱、构建 Object[] 参数数组；MethodHandle.invokeExact 则跳过全部这些，直接跳转到目标字节码。
示例对比：
立即学习“Java免费学习笔记（深入）”；
Method method = clazz.getDeclaredMethod("setValue", int.class);
method.setAccessible(true);
method.invoke(obj, 42); // 反射：每次都要校验 + 封装
MethodHandle mh = lookup.findVirtual(clazz, "setValue", methodType(void.class, int.class));
mh.invokeExact(obj, 42); // MH：类型已固定，零额外开销
-
invokeExact要求参数/返回值类型完全匹配；invoke会尝试自动适配（但慢，且可能失败） - 反射的
setAccessible(true)在 JDK 12+ 受强封装限制（尤其模块化后），而MethodHandle的Lookup实例若由本类创建，天然具备访问私有成员权限 - 反射异常是
InvocationTargetException包裹业务异常；MethodHandle异常直接透出，更利于调试
MethodHandle 容易踩的三个坑
不是“用了就快”，没踩对点反而更慢、更难维护。
- 误用
invoke替代invokeExact：只要类型稍有偏差（比如int传Integer），就会触发隐式转换逻辑，性能跌回反射水平，还容易抛WrongMethodTypeException - 忽略
MethodType构建成本：频繁调用methodType(...)创建相同类型描述，应复用静态常量或缓存 - 滥用
asType做适配：它生成新句柄，有额外对象分配和类型检查开销；应尽量在获取句柄时就用正确MethodType，或用dropArguments/insertArguments等组合器预处理
什么时候该选 MethodHandle 而不是反射
只在满足以下至少两个条件时才值得引入：
- 调用频率高（比如每毫秒调用数十次以上）
- 目标方法签名稳定（不依赖运行时字符串拼接方法名）
- 能接受编译期/启动期多花一点代码写句柄获取逻辑（比如用
static final MethodHandle MH_SET_VALUE = LOOKUP.findVirtual(...)）
如果只是偶尔调用、方法名来自配置或用户输入、或者需要遍历类的所有方法——老实用反射，别硬套 MethodHandle。它的优势只在“已知目标、高频直达”的窄场景里成立。
最容易被忽略的一点：MethodHandle 的异常堆栈不包含你写的调用行号，而是停在 invokeExact 这一行——调试时得倒推回去看哪个句柄绑错了类型。
