直接缓存methodhandle能显著减少重复查找和安全检查开销，因其调用路径更短、jit更易优化，且同一classloader下对固定方法签名的句柄线程安全、稳定复用。
直接缓存 MethodHandle 能显著减少重复查找和安全检查开销，比单纯缓存 Method 对象更进一步——因为 MethodHandle 本身已跳过大部分反射运行时校验，调用路径更短，JIT 更易优化。
缓存 MethodHandle 的核心逻辑
MethodHandle 不可跨类加载器复用，但同一 ClassLoader 下对固定方法签名（类+方法名+参数类型）的句柄是稳定且线程安全的。缓存的关键在于：用唯一键标识句柄，首次构建后复用，避免每次调用都走 lookup.findVirtual 或 findStatic 流程。
- 键建议采用
Class> + methodName + MethodType.toString()组合，确保类型精确匹配（如int.class和Integer.class视为不同） - 使用
ConcurrentHashMap存储，避免并发初始化竞争 - 不建议用 WeakReference 包裹句柄——MethodHandle 本身不持类引用，不会导致 ClassLoader 泄漏
一个可落地的缓存工具类示例
以下代码封装了 getter/setter 方法句柄的缓存逻辑，支持私有字段、带参数方法，且自动处理 setAccessible(true)：
public class MhCache {
private static final Map<string methodhandle> CACHE = new ConcurrentHashMap();
public static MethodHandle getGetter(Class> clazz, String fieldName) throws Throwable {
String key = "getter:" + clazz.getName() + "." + fieldName;
return CACHE.computeIfAbsent(key, k -> {
try {
Field field = clazz.getDeclaredField(fieldName);
field.setAccessible(true);
return MethodHandles.lookup()
.unreflectGetter(field);
} catch (Exception e) {
throw new RuntimeException(e);
}
});
}
public static MethodHandle getSetter(Class> clazz, String fieldName) throws Throwable {
String key = "setter:" + clazz.getName() + "." + fieldName;
return CACHE.computeIfAbsent(key, k -> {
try {
Field field = clazz.getDeclaredField(fieldName);
field.setAccessible(true);
return MethodHandles.lookup()
.unreflectSetter(field);
} catch (Exception e) {
throw new RuntimeException(e);
}
});
}
}
</string>
调用时只需一次获取，后续直接 invokeExact：
User user = new User(); MethodHandle getter = MhCache.getGetter(User.class, "name"); String name = (String) getter.invokeExact(user); // 比反射快 8–10 倍
配合 invokeExact 提升类型安全与性能
务必优先使用 invokeExact() 而非 invoke() 或 invokeWithArguments()。前者要求参数/返回值类型完全匹配，省去运行时类型转换和装箱拆箱，执行路径最短。
- 若方法签名为
void setName(String)，调用时必须传String实例，不能传Object - 编译期就能发现类型错误，避免
WrongMethodTypeException在运行时抛出 - JIT 编译器对
invokeExact的内联支持更好，实测比invoke快 20%–30%
注意边界场景与清理策略
缓存不是一劳永逸。需防范两类风险：
-
热部署/类重定义：当应用支持 JRebel 或 Spring DevTools 时，旧 Class 可能被卸载，对应句柄失效。此时应监听
ClassFileTransformer或使用基于 ClassLoader 的二级缓存隔离 - 内存增长失控：高频生成新方法（如动态脚本编译）可能填满缓存。可引入 Guava Cache 设置最大 size + LRU 策略，或按业务域分 namespace 清理（如 “orm-getter”、“rpc-handler”）
不复杂但容易忽略。
