Java MethodHandle 如何组合参数适配器：类型变换、调用链与 WrongMethodTypeException

把一段反射调用改成 MethodHandle 后，最容易踩的坑不是找不到方法，而是适配器接上了，调用点的签名却没有一起改变。结果通常是组合阶段就抛出 WrongMethodTypeException，或者 invokeExact 在看似相同的参数旁边突然失败。稳妥的做法是先写出目标 MethodType，再让每个适配器只负责一种类型变换，最后用一个固定签名的调用点验收。

MethodHandle 组合的核心是“先核对类型，再接调用链”：filterArguments 处理参数预加工，explicitCastArguments 处理明确的成对类型转换，invokeExact 则要求调用点签名与句柄类型完全一致。

先把目标签名固定下来：MethodHandle 与 MethodType

下面的例子模拟一个“把用户输入转成订单编号，再交给业务函数”的小调用链。目标方法只接收一个 String，返回一个 String；前置适配器把 Object 统一转成 String，这样边界很清楚，也方便观察异常究竟发生在哪一层。

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class HandleAdapterDemo {
    static String normalize(String raw) {
        return raw.trim().toUpperCase();
    }

    static String loadOrder(String orderId) {
        return "order:" + orderId;
    }

    public static void main(String[] args) throws Throwable {
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        MethodHandle normalize = lookup.findStatic(
                HandleAdapterDemo.class,
                "normalize",
                MethodType.methodType(String.class, String.class));
        MethodHandle loadOrder = lookup.findStatic(
                HandleAdapterDemo.class,
                "loadOrder",
                MethodType.methodType(String.class, String.class));

        System.out.println(normalize.type());
        System.out.println(loadOrder.type());
        System.out.println((String) loadOrder.invokeExact("a-17"));
    }
}

这里两个句柄的类型都是 (String)String。最后一行显式把返回值接成 String，是因为 invokeExact 会把调用点的静态签名直接拿来匹配；如果把返回结果先声明成 Object，调用点就变成 (String)Object，即使运行时结果仍是字符串，也不再是精确匹配。

用 filterArguments 把参数加工接到调用链

filterArguments 的思路是“先调用过滤器，再把返回值放回目标句柄的参数位置”。目标 loadOrder 接收一个 String，所以过滤器的返回值也必须是 String。下面把两个 (String)String 句柄接成一条链：

MethodHandle pipeline = MethodHandles.filterArguments(loadOrder, 0, normalize);

System.out.println(pipeline.type());
String result = (String) pipeline.invokeExact(" a-17 ");
System.out.println(result); // order:A-17

组合后的 pipeline 仍是 (String)String，但执行顺序已经变成 normalize 再到 loadOrder。如果把过滤器改成返回 int，而目标第 0 个参数仍是 String，组合时就会因为返回值无法接入目标参数而失败。这个失败比业务方法内部的异常更有价值：它说明调用链的静态边界已经不成立。

explicitCastArguments 和 asType 怎么选

当两端类型不完全相同但确实存在明确的转换关系时，可以考虑 explicitCastArguments。它要求新旧方法类型参数数量相同，按位置做参数和返回值转换，适合把“边界类型”写成显式契约。比如目标句柄是 (String)String，可以先适配成 (Object)Object，再把它交给使用对象类型的上层：

MethodType objectType = MethodType.methodType(Object.class, Object.class);
MethodHandle objectHandle = MethodHandles.explicitCastArguments(loadOrder, objectType);

Object result = (Object) objectHandle.invokeExact((Object) "a-17");
System.out.println(result);

asType 更像“按调用点允许的转换尝试适配”，会涉及引用转换、装箱拆箱或基本类型扩展；它适合边界已经稳定、转换规则也符合预期的场景。调试组合链时，我更建议先用 explicitCastArguments 把意图写出来，等类型验收稳定后再评估是否用 asType 减少样板。

WrongMethodTypeException 应该怎样定位

异常出现在组合调用时，通常看三处：过滤器返回值是否能接入目标参数、MethodType 的参数数量是否一致、以及 invokeExact 的调用点是否使用了完全相同的返回类型。不要只看变量声明，调用点的强制转换会改变签名。

三个容易误判的边界

把 invokeExact 当成普通方法调用

普通 Java 调用会按声明上下文处理一部分转换，invokeExact 不会替你补齐调用点签名。返回值要在调用点处转成目标类型，参数也要使用句柄实际需要的类型。

只打印方法名，不打印 type

适配器链里方法名相同并不能说明类型相同。调试时把每一步的 handle.type() 打出来，往往比继续追栈更快。

用很多适配器掩盖错误边界

适配器越多，出错位置越难判断。建议每接一层就打印一次类型，并为最终组合链保留一个最小的 invokeExact 验收例子。

相关问题

MethodHandle 比反射调用快吗？

不能只凭 API 名称下结论。它能把调用关系表示成可组合的句柄，但实际收益取决于调用形态、热身、类型稳定性和运行时优化，应该用贴近业务的基准验证。

为什么 invoke 能运行而 invokeExact 失败？

invoke 允许按调用点尝试适配，invokeExact 要求调用点描述符与句柄类型完全一致，所以后者更适合做类型契约的验收。

什么时候应该停止组合继续改业务代码？

当适配器开始承担业务分支、异常恢复或隐式状态时，调用链已经难以复核。保留少量类型适配，把业务判断放回普通 Java 方法，通常更易维护。

把类型检查变成组合链的验收动作

MethodHandle 的可维护性不在于把所有调用都改成动态句柄，而在于每一次组合都能回答两个问题：输入会变成什么类型，下一步调用点要求什么类型。用 MethodType 记录边界，用 filterArguments 表达参数预处理，用 explicitCastArguments 表达明确转换，最后用 invokeExact 固定验收点，出现 WrongMethodTypeException 时就能沿着这条短链定位。