ki-pi前几天一个准备去同城旅行面试的朋友跑来问我：“MethodHandle 和反射到底哪个快？底层区别是什么？面试官现场追问得很深，我背了半天八股，还是没底。”我听完之后跟他说，这道题能问出水平，恰恰不是因为它在考“结论”，而是因为这两个东西背后，藏着 Java 对“动态调用”的一套完整演进逻辑。你要是只会背“MethodHandle 快、反射慢”，遇到稍有经验的面试官，基本撑不过下一个追问。
先说清楚我写这篇文章的定位：不是给你一份背诵材料，而是把反射慢在哪、MethodHandle 为什么能快、以及面试官想从答案里听到的层次全部拆开讲。看完之后你既能答这道题，也能在真实项目里判断“这个热点到底该不该换成 MethodHandle”。
1. 想要答好这道题，先得明白面试官为什么盯上 MethodHandle
1.1 这个问题表面上问性能，实际问的是对动态调用演进的理解
很多 Java 面试者会把“反射 vs MethodHandle”当成一个单纯的性能工具对比题来准备，这是最大的误解。MethodHandle 不是 JDK 顺手做的一个“反射替代品”，它是 JSR 292 引入的一套底层机制，是 invokedynamic 指令能够落地的基础设施之一。从 JDK 7 开始，Java 平台想解决的是 JVM 上动态类型语言（比如 JRuby、Groovy）调用性能差的问题，所以设计出了“方法句柄”这样一个能被 JVM 直接识别和优化的可调用目标。
等你看到 JDK 8 里 Lambda 表达式就是通过 invokedynamic 加 LambdaMetafactory 实现的，就会明白：MethodHandle 并不是一个孤立 API，它代表着 Java 从“运行时的元信息描述”走向“运行时的高性能调用抽象”。所以同城旅行这类一线互联网公司问这道题，要的是你能否站在平台设计的高度去解释“为什么会有这个东西”，而不是单纯报一个 Benchmark 数据。
1.2 “MethodHandle 就是更好的反射”这个前提本身是错的
我见过不少面试者在回答里先说“MethodHandle 是 JDK 7 提供的，用于替代反射”。这句话很容易被抓住反问：那为什么 Spring、MyBatis 还在大量使用反射？为什么 JDK 自身很多地方也没全部改成 MethodHandle？
答案在于两者解决的问题不同。反射（Reflection）更准确地说是 Java 的“自省（introspection）能力”，它把类、方法、字段抽象成可描述、可遍历、可修改的元数据对象，让你在运行时看清一个类长什么样。MethodHandle 则是“调用能力”，它不太关心类结构长什么样，它关心的是“你能不能拿到一个目标，然后直接调用它”。
用生活化一点的话说：反射像一本厚厚的数据库字典，你拿到它之后可以查表、分析、筛选；MethodHandle 像一把已经配好齿的钥匙，钥匙本身不带任何“表结构”的说明，只是插进锁就能转。两者有关联，但目标和成本结构完全不同。
所以一道优秀面试题的起点，不是让你选边站，而是让你把这两个机制的边界说清楚。我会在后面给一个分层的回答框架，那是更适合面试的表达方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 反射的性能损耗，主要发生在哪几个调用环节
2.1 Object[] 参数的装箱与拆箱
讨论反射“慢”之前，先建立一个共识：不能拿反射和直接调用比“功能”，它们根本不是同一种成本量级。但如果你确实要在一个热点循环里反复调用某个方法，反射的第一个明显损耗来自方法签名。
看 Method.invoke 的方法签名：
java复制public Object invoke(Object obj, Object... args)
也就是说，不管实际方法接收的是 String、int 还是别的类型，你都必须把入参装进 Object[]。基本类型必然发生装箱，返回值也必然以 Object 形式返回，调用方再自己强转。这中间产生的对象分配、类型转换，在每一次调用里都会重复出现。
这个损耗的重要性在于它会影响 JIT 优化。你写普通代码 service.greet("name") 的时候，编译器知道入参就是 String，返回值就是 String，JIT 可以做非常激进的分析。一旦变成 method.invoke(service, new Object[]{"name"})，JIT 很难猜出目标方法的真实签名，许多逃逸分析、标量替换、方法内联都施展不开。损失的不只是这一次调用的装箱，而是整个优化链路的失效。
2.2 每次 invoke 都要面对的方法可见性校验
第二笔成本在访问控制。Java 反射的设计初衷是“可信调用者可以检查任意类成员”，所以 Method.invoke 内部需要确保调用者对当前方法有访问权。
早期的反射实现里，这层检查成本相当高，因为 JVM 无法假定一个 Method 对象是可信来源，调用链上需要反复校验调用者栈帧、类加载器、方法可见性。虽然后面的 JDK 做了大量优化，比如某些访问检查能被缓存，但“每层都要做权限确认”这种保守逻辑，仍然会让通用反射调用路径比直接调用重得多。
你去看 Java 9 模块系统出现之后，反射调用还要额外考虑模块是否对调用方开放导出包，否则即使 setAccessible(true) 也可能抛 InaccessibleObjectException。这种模块边界的判断，本身也是一次运行时开销和复杂度来源。