methodhandle并非天生比反射快，仅在重复调用同一缓存句柄且类型严格匹配（invokeexact逐字节一致）时，jvm才可能内联优化；单次调用因lookup、类型检查等初始化开销反而更慢。

MethodHandle 本身不比反射快，只有在反复调用同一缓存句柄 + 类型严格匹配时，JVM 才可能内联优化；单次调用反而更慢，因为 lookup.findVirtual、类型检查、句柄构建都有初始化开销。

---

为什么 invokeExact 一调就抛 WrongMethodTypeException

这不是 bug，是设计使然：invokeExact 要求实参类型、数量、返回类型与句柄的 type() 描述符**逐字节一致**，连 int 和 Integer 都不兼容。

常见错误现象：

• 传 Integer.valueOf(42) 给声明为 int 参数的句柄 → 炸
• 方法签名是 void foo(String)，却用 MethodType.methodType(void.class, Object.class) 去查 → 查到的句柄类型不匹配 → invokeExact 炸
• 没打印 handle.type() 就硬调，参数对不上还怪句柄“不稳定”

调试建议：

• 每次拿到句柄后立刻加一行：System.out.println(handle.type());
• 确保 findXXX 传入的 MethodType 和目标方法签名完全一致（用 IDE 的 “Go to Declaration” 确认）
• 需要装箱/转型？别靠 invoke 混过去，改用 asType 在初始化阶段一次性转好并缓存

---

Lookup 权限失效：本地 OK，上线就 IllegalAccessException

JDK 9+ 模块系统下，MethodHandles.lookup() 返回的 Lookup 实例默认只对本模块 public 成员有效；跨模块访问 private 或 package-private 方法会静默失败（findVirtual 返回 null）或抛 IllegalAccessException。

典型踩坑点：

• 工具类里封装了 getHandle(Class, String, MethodType)，但 lookup() 是从工具类里调的 → 权限基于工具类，不是调用方类
• 想访问 com.example.internal.Utils.doWork()，但没在 module-info.java 中 opens com.example.internal to your.module;
• 查 private 方法时没用 MethodHandles.privateLookupIn(TargetClass.class, MethodHandles.lookup())

正确做法：

• Lookup 必须在目标类的静态上下文中获取：static final MethodHandle HANDLE = MethodHandles.lookup().findStatic(...);
• 跨模块访问非 public 成员，必须用 privateLookupIn，且目标模块需导出或开放包
• 永远检查 findXXX 返回值是否为 null，尤其在模块化环境中

---

性能陷阱：为什么压测发现比反射还慢

根本原因只有一个：你没复用句柄。每次调用都走一遍 lookup.findStatic + asType，等于把反射的“查找开销”换成了更重的句柄构建开销。

关键事实：

• MethodHandle 的 JIT 优化依赖**稳定调用链**：同一个句柄被反复调用，JVM 才会尝试内联；句柄一变，优化归零
• asType 每次都生成新句柄，破坏稳定性；应只在初始化时做一次，并缓存结果
• invoke 表面“能跑”，实则动态插入适配逻辑（如 Integer → int），开销比 invokeExact 高一个数量级，且无法内联

实操建议：

• 句柄必须 static final 缓存，或至少放在单例/对象字段中复用
• 避免在循环、lambda、Stream 中现场创建句柄
• 高频调用场景（如 JSON 反序列化 setter）只用 invokeExact，并确保类型零误差
• 不要为了“通用”而牺牲类型安全——泛型擦除后 asType 失效，性能和正确性双崩

---

真正难的不是写对第一行 MethodHandles.lookup()，而是守住类型边界、管住句柄生命周期、看清模块权限边界。这些地方一松动，MethodHandle 就退化成又慢又脆的反射。