MethodHandle比反射快的关键在于绕过运行时安全检查与参数包装开销，并支持JIT内联和去虚拟化优化；其性能优势需通过复用句柄、使用invokeExact、精确指定类型并充分预热才能稳定发挥。
MethodHandle 比反射快的关键在哪？
不是因为“底层更底层”，而是因为 MethodHandle 绕过了反射的大部分安全检查与包装开销，且 JVM 对它做了深度内联和去虚拟化优化。传统 Field.get() 或 Method.invoke() 每次调用都要走 AccessibleObject.checkAccess()、参数数组装箱、异常封装（InvocationTargetException）、甚至可能触发类初始化检查；而 MethodHandle 在首次解析后得到的是一个可直接跳转的句柄，后续调用接近静态方法性能。
怎么正确构造用于属性读写的 MethodHandle？
别直接用 MethodHandles.lookup().findGetter() 传 Object.class —— 这会生成泛型句柄，JVM 无法有效优化。必须精确指定目标类和字段类型：
Field field = Target.class.getDeclaredField("id");
MethodHandle getter = MethodHandles.lookup()
.findGetter(Target.class, "id", int.class); // ✅ 明确类型
// 而不是 .findGetter(Object.class, "id", int.class) ❌
- 字段必须是 public，或提前调用
field.setAccessible(true)（只在 lookup 前调一次，不影响后续 MH 性能） - 对 private 字段，
findGetter和findSetter仍需权限绕过，但仅发生在构造阶段，不参与每次调用 - 避免重复构造：把
MethodHandle缓存为static final或放入ConcurrentHashMap，不要每次访问都lookup
调用时怎么避免装箱和类型转换开销？
MethodHandle.invokeExact() 是关键——它要求参数和返回类型完全匹配，不自动拆/装箱、不执行隐式转换。一旦类型不符，立刻抛 WrongMethodTypeException，而不是默默降级为慢路径。
MethodHandle mh = lookup.findVirtual(String.class, "length", methodType(int.class));
int len = (int) mh.invokeExact("hello"); // ✅ invokeExact + 强制类型断言
// 如果写成 mh.invoke("hello") → 触发适配器生成，性能掉回反射水平
- 永远优先用
invokeExact()，配合明确的泛型或类型断言 - 如果参数类型不确定（比如来自 JSON 的
Object），先做一次类型检查再分发，而不是依赖invoke()的动态适配 - 对基本类型字段，getter/setter 的
MethodHandle必须声明对应原始类型（int.class，非Integer.class），否则会触发自动装箱
为什么缓存 Lookup 实例反而可能出问题？
MethodHandles.Lookup 是有访问上下文的：它继承调用点的包/模块权限。跨类复用同一个 Lookup 实例（比如 static 缓存），可能导致对其他类的私有成员访问失败，或在模块化环境（Java 9+）下抛 IllegalAccessException。
- 每个需要构造
MethodHandle的类，应使用自己的MethodHandles.lookup() - 不要把
Lookup存为字段或共享变量 - 真正该缓存的是构造好的
MethodHandle，不是Lookup - 在模块中使用时，确保目标类所在模块已对
java.base（或你的模块）开放了包（opens xxx to java.base）
实际压测中，50%+ 的提升只在高频、小对象、固定字段场景下稳定出现；如果每次都要重新查找、或者混用 invoke() 和装箱类型，性能可能比反射还差。最易被忽略的一点：MethodHandle 的 JIT 优化需要足够预热——刚启动时跑不出理论速度，至少几千次调用后才趋于稳定。
