Java 用 MethodHandle 替代反射:调用性能实测、invokeExact 的坑与缓存写框架、序列化库、动态代理时,免不了要「运行时调用一个编译期不知道的方法」。绝大多数人第一反应是反射:Method.invoke。能用,但在热路径上它有两个老毛病——调用有装箱和访问检查开销,而且 JIT 很难对它做深度内联优化。Java 7 引入的MethodHandle是为动态调用重新设计的一套机制,底层直接对接invokedynamic字节码指令,JIT 能把它当成近似直接调用来优化。这篇实测两者的性能差距,把invokeExact这个最容易踩的坑讲清楚,并给出正确的缓存姿势。反射调用慢在哪先看反射的典型写法:MethodmUser.class.getMethod(getName);Stringname(String)m.invoke(user);// 每次调用都有开销Method.invoke的开销主要来自三块:每次调用做访问权限检查(除非你setAccessible(true));参数用Object[]包装,基本类型要装箱;返回值是Object,还得强转。更关键的是,invoke内部是一大段通用逻辑,JIT 难以针对某个具体方法做内联。MethodHandle的思路完全不同:在查找阶段就把访问检查、方法解析全做完,得到一个「已经绑定好」的句柄;真正 invoke 时几乎是直达目标方法,JIT 可以像优化普通方法调用一样优化它。MethodHandle 基本用法三步:拿Lookup→ 描述方法签名MethodType→findVirtual查句柄:importjava.lang.invoke.*;MethodHandles.LookuplookupMethodHandles.lookup();// MethodType.methodType(返回类型, 参数类型...)// getName 无参、返回 StringMethodTypetypeMethodType.methodType(String.class);// findVirtual:查实例方法。句柄的第一个参数是接收者(this)MethodHandlehandlelookup.findVirtual(User.class,getName,type);// 调用:第一个实参传接收者对象Stringname(String)handle.invoke(user);findVirtual/findStatic/findConstructor/findGetter分别对应实例方法、静态方法、构造器、字段读取。MethodType精确描述签名,这也是它性能好的原因之一:签名在查找期就固定了。最大的坑:invokeExact 与 invoke 的区别MethodHandle有两个调用方法,长得像但行为差很多,新手几乎必踩:invokeExact:要求调用点的签名和句柄的MethodType一字不差,包括返回值的强转类型。它最快,但最挑剔。invoke:允许运行时做必要的类型适配(装箱、拆箱、拓宽、强转),更宽松,但有一点适配开销。看这个经典报错:MethodTypetypeMethodType.methodType(String.class);MethodHandlehlookup.findVirtual(User.class,getName,type);// invokeExact 要求:返回类型必须显式强转成句柄声明的 StringObjectrh.invokeExact(user);// 运行时抛 WrongMethodTypeException!// 因为句柄返回 String,而这里期望 Object,签名对不上正确写法是让调用点签名和句柄完全一致——接收者类型、返回强转都要对齐:// 返回值必须强转为 String(和 MethodType 声明一致)// 接收者 user 的静态类型也要是 UserStringr(String)h.invokeExact(user);记住一条:invokeExact的每个实参静态类型 返回值强转类型,要和MethodType逐一对应。哪怕把String写成Object都会抛WrongMethodTypeException。搞不定精确匹配时先用invoke保证正确,确认签名后再换invokeExact榨性能。性能实测:句柄一定要缓存MethodHandle快的前提是句柄被复用。findVirtual本身不便宜(要解析、做访问检查),如果每次调用都重新 find,反而比反射还慢。正确姿势是把句柄查一次、缓存成static final:publicfinalclassNameAccessor{privatestaticfinalMethodHandleGET_NAME;static{try{GET_NAMEMethodHandles.lookup().findVirtual(User.class,getName,MethodType.methodType(String.class));}catch(ReflectiveOperationExceptione){thrownewExceptionInInitializerError(e);}}publicstaticStringgetName(Useru){try{return(String)GET_NAME.invokeExact(u);}catch(Throwablet){thrownewRuntimeException(t);}}}static final这个修饰不只是习惯:JIT 对static final MethodHandle有特殊优化,能把它当成常量,内联到近乎直接调用。放在实例字段或局部变量里,这层优化就享受不到。同样的道理也适用于反射侧对比:公平的 benchmark 应该两边都缓存(Method也setAccessible(true)并复用)。在缓存 预热到位的 JMH 测试里,invokeExact的调用开销通常能明显低于Method.invoke,尤其在有基本类型参数、装箱压力大的场景差距更明显;而如果不缓存句柄,MethodHandle 会输得很惨。什么时候用哪个反射:一次性调用、启动期扫描注解、调用频率极低的场景。写起来直观,getMethod/invoke心智负担小。MethodHandle:热路径上的高频动态调用,且句柄能被缓存复用。序列化库、ORM、模板引擎的字段存取,是它的主场。需要极致性能且能接受代码生成:再往上还有LambdaMetafactory,能把MethodHandle变成一个真正的函数式接口实例(如Function),调用开销进一步逼近直接调用——但那是另一篇的话题。小结反射慢在每次调用的访问检查、装箱和难以内联;MethodHandle把这些开销前置到查找阶段。用findVirtual/findStatic/findConstructor拿句柄,MethodType精确描述签名。invokeExact要求签名逐一精确匹配(含返回值强转),不匹配抛WrongMethodTypeException;搞不定先用invoke。句柄必须缓存成static final,否则每次findVirtual的开销会让它比反射还慢,而且static final才能吃到 JIT 常量内联。低频调用用反射够了,高频热路径且句柄可复用才上 MethodHandle。一句话记忆:MethodHandle 的性能红利,全押在「句柄缓存复用」和「invokeExact 签名精确匹配」这两件事上,任缺一个都白干。