MethodHandle调用比Method.invoke()快，根本原因是绕过每次调用的安全检查、避免参数装箱拆箱与类型转换、支持JIT内联优化，且权限校验仅在创建时执行一次。
MethodHandle 的性能优势不是靠“魔法”，而是靠绕过反射的运行时检查、统一类型校验时机、以及 JIT 友好性——它本质是 JVM 为动态调用设计的“第一公民”。
为什么 MethodHandle 调用比 Method.invoke() 快？
根本原因在于调用路径上少了三类开销：
- 每次
Method.invoke()都要重新做SecurityManager检查（即使已调用过setAccessible(true)）；MethodHandle在Lookup.findXXX()时只做一次权限校验，后续调用完全跳过 -
Method.invoke()接收Object...参数，需在每次调用时拆包、装箱、类型转换；MethodHandle是强类型的，invokeExact()直接按MethodType约定的签名传参，零额外转换 - JIT 编译器对
Method.invoke()基本不内联（多态+反射标记），但对MethodHandle.invokeExact()会当作普通方法调用处理，可内联、可去虚化、可常量传播
MethodHandle 的创建成本高，但复用收益大
创建 MethodHandle 本身比获取 Method 对象慢（涉及符号解析、字节码验证、句柄生成），所以不能“用一次建一次”。关键策略是缓存：
- 对固定类+方法名+签名组合，用
ConcurrentHashMap缓存MethodHandle实例，键可为Class<?> + methodName + MethodType字符串或自定义 key - 避免在循环内重复调用
lookup.findVirtual()；ORM 映射字段 setter 场景中，应在类初始化阶段或首次实例化时完成句柄构建 - 注意
MethodHandles.Lookup是轻量对象，但不可跨类使用（它的权限基于创建时的lookupClass()）；不要试图复用其他类的Lookup实例来查找私有方法
invokeExact vs invoke：类型安全的取舍
二者区别直接影响性能和稳定性：
-
invokeExact()要求参数/返回值类型与MethodType完全一致（包括基本类型 vs 包装类），失败直接抛WrongMethodTypeException；这是 JIT 最易优化的路径 -
invoke()允许自动装箱、拆箱、向上转型，但会触发适配器生成（MethodHandle.asType()内部逻辑），带来额外开销和 GC 压力 - 除非你明确需要运行时类型宽松（如泛型桥接场景），否则一律优先用
invokeExact()；调试时若报WrongMethodTypeException，说明MethodType构造错了，比如把int.class写成Integer.class
容易被忽略的兼容性陷阱
看似简单的替换，实际埋着几个 runtime 层面的坑：
-
private方法句柄必须由其所在类内部创建Lookup（即MethodHandles.privateLookupIn(targetClass, MethodHandles.lookup())在 JDK 9+ 才支持跨类访问，JDK 8 不行） - 静态方法用
findStatic()，实例方法用findVirtual()或findSpecial()（后者绕过重写，类似invokespecial），选错会导致NoSuchMethodException或语义错误 - 字段访问不能直接用
findVirtual；得用findGetter()/findSetter()，且它们返回的是操作字段的句柄，不是字段本身的句柄 - JDK 15+ 默认启用
--illegal-access=deny，反射能绕过的限制，MethodHandle同样受约束——权限检查更早、更严格，不是“反射的更快替代品”，而是“更干净的替代品”
真正发挥 MethodHandle 价值的前提，是接受它“编译期契约更强、运行时更薄”的设计哲学：它不帮你兜底，但只要你守约，JVM 就敢把它当普通方法优化。滥用 asType()、频繁重建句柄、或拿它当反射的语法糖来用，反而会让性能更差。
