对问题的回答

问题的历史

在 Java 7 中通过 JSR 292 引入的 invokedynamic 带来了 MethodHandle API，以支持在 JVM 上的动态语言实现。挑战在于 MethodHandle.invoke 需要接受任何组合的参数类型和返回类型，而不必声明成千上万的重载。JVM 架构师通过引入内置于 java.lang.invoke 包中的 @PolymorphicSignature 注解概念来解决这个问题。

问题描述

标准的 Java 方法调用要求编译器发出一个invokevirtual（或类似）指令，引用与方法声明签名完全匹配的常量池中的特定方法描述符。如果 MethodHandle.invoke 被声明为接受 Object... 参数，则每个调用站点都需要装箱和数组分配，违背了性能目标。相反，为每种可能的签名组合声明重载是不可能的，这将无限膨胀 Class 文件。

解决方案

JVM 特殊处理带有 @PolymorphicSignature 注解的方法。当编译器遇到对这样的一个方法的调用时，它忽略声明的签名，而是生成一个 invokevirtual 指令，其方法描述符正好与调用站点的参数和返回类型的擦除类型匹配。这允许 MethodHandle.invokeExact 在源代码中看起来像接受 (Object)Object，但在特定调用站点上编译为 (String)int。然后，JVM 将此调用直接链接到目标方法的入口点，而没有适配器开销。

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

public class PolymorphicExample {
    public static void main(String[] args) throws Throwable {
        MethodHandle handle = MethodHandles.lookup()
            .findVirtual(String.class, "length", 
                MethodType.methodType(int.class));
        
        // 编译器生成的 invokevirtual 描述符为 (String)int
        // 尽管 invokeExact 被声明为 (Object)Object 在字节码中
        int result = (int) handle.invokeExact("hello"); 
        System.out.println(result); // 输出: 5
    }
}

生活中的情况

问题描述

在为金融滴答数据构建高吞吐量事件处理框架时，我们需要使用反射类似的灵活性将传入的消息调度到已注册的处理程序，但不产生分配开销。每个处理程序方法都有不同的签名——有些接受 long 时间戳，有些接受 BigDecimal 价格——在不装箱原始类型的情况下进行通用调度变得具有挑战性。

考虑的不同解决方案

动态字节码生成 涉及使用 ASM 或 ByteBuddy 在注册时为每个处理程序签名生成代理类。此方法在预热后提供了接近本地的性能，但消耗了大量的 Metaspace，并在类加载和 JIT 编译期间将应用程序启动延迟增加了几秒钟。它还为调试生成的代码增加了维护复杂性。

使用方法句柄的反射 利用标准的 Method.invoke 然后进行 unreflect 以获取 MethodHandle。虽然实现更简单，但这对原始参数征收了装箱成本，并阻止了 HotSpot 通过反射层进行内联。性能测试显示与直接调用相比，调度速度慢了 10 到 15 倍，违反了我们的延迟要求。

多态签名利用 需要在调用 invokeExact 之前小心地将参数转换为确切期望的类型。这允许编译器为每个调用站点生成签名特定的 invokevirtual 指令，有效地将 MethodHandle 视为类型化的函数指针。权衡是编译时类型严谨性——我们必须在注册过程中验证处理程序签名以确保类型安全，如果签名不匹配，代码将无法编译。

选择的解决方案及原因

我们选择了多态签名方法，结合注册时验证层。通过生成轻量级适配器 lambdas（使用 LambdaMetafactory 和 invokedynamic）以匹配精确的 MethodHandle 签名，我们在保持类型安全的同时实现了直接调用性能。JVM 可以通过 MethodHandle 内联到实际的处理方法，完全消除了调度开销。

结果

该系统每秒处理 250 万个事件，延迟小于微秒，达到了手写调度代码的性能。与基于反射的原型相比，GC 压力降低了 98%，因为在调用路径中原始参数不再需要进行装箱。该解决方案保持了可维护性，因为类型错误在编译时而非运行时被捕获。

候选人常常遗漏的内容

为什么 MethodHandle.invoke() 允许类型转换，而 invokeExact() 则要求精确的签名匹配，尽管二者都具有多态签名？

这两个方法都携带 @PolymorphicSignature 注解，但是 invokeExact 在 JVM 级别执行严格的签名检查。当编译器为 invokeExact 生成 invokevirtual 指令时，它使用调用站点的确切擦除类型。JVM 然后验证这些类型是否与目标 MethodType 精确匹配。相反，invoke（不带 Exact）包括逻辑来使用 MethodHandle.asType 适配器调整调用站点类型到目标类型，这些适配器执行装箱、拆箱和原始类型转换。这种适配发生在 MethodHandle 实现内部，而不是在调用站点，因此 invoke 更灵活，但由于适配器链的开销可能更慢。

JVM 如何防止类型安全违规，如果多态签名方法允许任意方法描述符？

JVM 依赖于 Java 编译器在源级别强制执行类型安全。由于 @PolymorphicSignature 仅限于 java.base 模块类（如 MethodHandle 和 VarHandle），用户代码无法声明新的多态方法。编译器仅允许在可以验证调用站点的参数类型与预期签名匹配的情况下进行多态调用。对于 invokeExact，编译器插入隐式强制转换，以确保生成的描述符与程序员所期望的匹配。JVM 信任编译器已执行此验证，从而允许它在调用期间跳过运行时描述符检查，从而在保持通过编译时约束实现零开销的同时维护安全性。

为什么多态签名方法在堆栈跟踪和调试中似乎被擦除为 Object 类型，但却用特定的原始类型执行？

javac 编译器在这些方法的 class 文件中发出 @PolymorphicSignature 属性。当 JVM 将对这样的一个方法的调用进行解析时，它用调用站点的常量池条目的描述符替代声明的描述符。这意味着实际的字节码执行使用特定类型（int、long 等），但方法的元数据在 Class 对象中保留了声明的签名（通常为 (Object...)Object）以用于反射目的。因此，堆栈跟踪显示擦除形式，因为 Throwable.fillInStackTrace 使用的是方法元数据中的符号描述符，而不是在实际调用期间使用的动态描述符。这一差异使得开发人员困惑，因为他们期望在调试器中看到确切的参数类型。

编译器通过什么具体的 JVM 级别契约识别多态签名方法，从而使得能够发出覆盖声明签名的调用站点特定方法描述符？

对问题的回答

生活中的情况

候选人常常遗漏的内容