Java 用 MethodHandle 替代反射:调用性能实测、invokeExact 的坑与缓存

写框架、序列化库、动态代理时,免不了要「运行时调用一个编译期不知道的方法」。绝大多数人第一反应是反射:Method.invoke。能用,但在热路径上它有两个老毛病------调用有装箱和访问检查开销,而且 JIT 很难对它做深度内联优化。

Java 7 引入的 MethodHandle 是为动态调用重新设计的一套机制,底层直接对接 invokedynamic 字节码指令,JIT 能把它当成近似直接调用来优化。这篇实测两者的性能差距,把 invokeExact 这个最容易踩的坑讲清楚,并给出正确的缓存姿势。

反射调用慢在哪

先看反射的典型写法:

java 复制代码

Method m = User.class.getMethod("getName");
String name = (String) m.invoke(user); // 每次调用都有开销

Method.invoke 的开销主要来自三块:每次调用做访问权限检查 (除非你 setAccessible(true));参数用 Object[] 包装,基本类型要装箱 ;返回值是 Object,还得强转。更关键的是,invoke 内部是一大段通用逻辑,JIT 难以针对某个具体方法做内联。

MethodHandle 的思路完全不同:在查找阶段就把访问检查、方法解析全做完,得到一个「已经绑定好」的句柄;真正 invoke 时几乎是直达目标方法,JIT 可以像优化普通方法调用一样优化它。

MethodHandle 基本用法

三步:拿 Lookup → 描述方法签名 MethodType → findVirtual 查句柄:

java 复制代码

import java.lang.invoke.*;

MethodHandles.Lookup lookup = MethodHandles.lookup();

// MethodType.methodType(返回类型, 参数类型...)
// getName 无参、返回 String
MethodType type = MethodType.methodType(String.class);

// findVirtual:查实例方法。句柄的第一个参数是接收者(this)
MethodHandle handle = lookup.findVirtual(User.class, "getName", type);

// 调用:第一个实参传接收者对象
String name = (String) handle.invoke(user);

findVirtual / findStatic / findConstructor / findGetter 分别对应实例方法、静态方法、构造器、字段读取。MethodType 精确描述签名,这也是它性能好的原因之一:签名在查找期就固定了。

最大的坑:invokeExact 与 invoke 的区别

MethodHandle 有两个调用方法,长得像但行为差很多,新手几乎必踩:

invokeExact :要求调用点的签名和句柄的 MethodType 一字不差,包括返回值的强转类型。它最快,但最挑剔。
invoke:允许运行时做必要的类型适配(装箱、拆箱、拓宽、强转),更宽松,但有一点适配开销。

看这个经典报错:

java 复制代码

MethodType type = MethodType.methodType(String.class);
MethodHandle h = lookup.findVirtual(User.class, "getName", type);

// invokeExact 要求:返回类型必须显式强转成句柄声明的 String
Object r = h.invokeExact(user);
// 运行时抛 WrongMethodTypeException!
// 因为句柄返回 String,而这里期望 Object,签名对不上

正确写法是让调用点签名和句柄完全一致------接收者类型、返回强转都要对齐:

java 复制代码

// 返回值必须强转为 String(和 MethodType 声明一致)
// 接收者 user 的静态类型也要是 User
String r = (String) h.invokeExact(user);

记住一条:invokeExact 的每个实参静态类型 + 返回值强转类型,要和 MethodType 逐一对应 。哪怕把 String 写成 Object 都会抛 WrongMethodTypeException。搞不定精确匹配时先用 invoke 保证正确,确认签名后再换 invokeExact 榨性能。

性能实测:句柄一定要缓存

MethodHandle 快的前提是句柄被复用 。findVirtual 本身不便宜(要解析、做访问检查),如果每次调用都重新 find,反而比反射还慢。正确姿势是把句柄查一次、缓存成 static final:

java 复制代码

public final class NameAccessor {
    private static final MethodHandle GET_NAME;

    static {
        try {
            GET_NAME = MethodHandles.lookup()
                .findVirtual(User.class, "getName",
                    MethodType.methodType(String.class));
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    public static String getName(User u) {
        try {
            return (String) GET_NAME.invokeExact(u);
        } catch (Throwable t) {
            throw new RuntimeException(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 签名精确匹配」这两件事上,任缺一个都白干。