问题的历史。
当 Java 5 引入带参数的类型时，语言采用了类型擦除以保持与在泛型之前编译的遗留代码的二进制兼容性。这一设计决定意味着在 JVM 层面上，所有的泛型类型参数都被替换为其原始边界——通常是 Object，因此没有实际类型参数的运行时痕迹。因此，当一个具体类实现一个像 Comparable<String> 这样的接口时，compareTo 的擦除签名变为 compareTo(Object)，而实现类声明为 compareTo(String)。如果不进行干预，JVM 将无法链接这些方法，将它们视为不同的实体而不是多态重写。
问题的描述。
核心问题表现为编译后的客户端代码与实现类之间的二进制不兼容。编译针对泛型接口的客户端代码期待一个原始签名的方法（例如 compareTo(Object)），但实现类只提供具体签名（例如 compareTo(String)）。在运行时，JVM 根据常量池中的描述符执行方法分发；如果描述符 (Ljava/lang/Object;)I 不匹配具体实现，虚拟机将抛出 AbstractMethodError 或完全调用错误的方法。这一差距阻止了泛型接口的真正多态行为，并且需要一种机制来调和擦除的合同与具体实现。
解决方案。
Java 编译器通过在实现类中生成一个具有擦除原始签名的合成桥接方法来解决此问题。这个桥接方法在字节码中标记为 ACC_BRIDGE 和 ACC_SYNTHETIC 访问标志，表明它是由编译器生成的，不存在于源代码中。桥接方法仅通过对其参数进行未经检查的转换并调用真实方法来委托给实际实现。此委托确保 JVM 方法解析算法在运行时找到匹配的描述符，而桥接中的转换强制执行在编译时验证的类型安全约束。
interface Node<T> { void setData(T data); } class StringNode implements Node<String> { @Override public void setData(String data) { System.out.println(data.toLowerCase()); } }
在上面的例子中，编译器在 StringNode 中生成一个合成方法 public void setData(Object data)，将参数转换为 String 并调用真正的 setData(String)。
问题描述。
在设计内容管理系统的模块化插件架构时，我们需要一个 EventHandler<T> 接口，以便插件可以为 UserLoginEvent 或 DocumentSaveEvent 等事件实现特定类型的处理程序。使用原始类型的初始原型能够正常工作，但迁移到泛型会暴露出动态加载的插件类在事件总线尝试通过泛型接口分发事件时偶尔会触发 AbstractMethodError。此问题仅在特定的 JDK 版本和复杂的类加载器层次结构下出现，使其难以一致重现。
考虑的不同解决方案。
其中一种方法涉及完全消除泛型，使用原始 Object 类型并在每个处理程序实现中进行手动 instanceof 检查。这一策略在不同 JDK 版本之间提供了广泛兼容性，并完全避免了合成方法的复杂性。然而，它牺牲了编译时的类型安全，迫使开发人员编写易于在运行时导致 ClassCastException 的样板转换逻辑。随着事件类型数量的增加，维护负担显著增加，代码变得杂乱无章，充满了不受检查的警告，掩盖了真正的类型错误。
另一种选择需要在运行时使用 java.lang.reflect.Proxy 生成动态代理，以拦截方法调用并自动执行类型适配。这个解决方案为插件作者保持了类型安全，同时在内部处理了擦除不匹配的问题。不幸的是，代理方法由于反射和方法调用开销引入了大量的性能开销，并且通过向堆栈跟踪添加间接层来复杂化调试。此外，它要求事件总线维护代理实例和实际插件实例之间的复杂映射逻辑，从而增加了内存占用。
选择的解决方案采用编译器的桥接方法生成，确保所有插件接口都是正确的泛型，并且实现类是使用 Java 5+ 编译器编译的。我们添加了使用 ASM 的字节码验证测试，以确认在加载之前合成方法在编译的插件类中是存在的。这种方法保持零运行时开销，保持完整的类型安全，并遵循标准 Java 编译实践，而无需自定义类加载器操作。
选择了哪个解决方案以及原因。
我们选择了标准的桥接方法，因为它利用了编译器的保证行为，而不是引入运行时复杂性。与手动转换不同，通过合成桥接的转换在调用站点强制执行类型约束，如果违反类型安全，则快速失败并抛出 ClassCastException。与动态代理相比，它消除了反射开销，并保持了干净、可解释的堆栈跟踪。这个解决方案与我们在最大限度降低运行时开销的同时，实现最高的编译时验证的目标一致。
结果。
在强制执行正确的泛型声明并添加编译时字节码验证后，AbstractMethodError 事件完全停止。插件开发者可以全力以赴地实现 EventHandler<UserLoginEvent>，确信事件总线会正确路由事件，而无需手动转换。该架构扩展到支持五十多种不同的事件类型，没有类型安全事件，并且性能剖析确认没有因合成方法而导致的可测量开销。
反射如何区分桥接方法和实际实现方法，这种区别在动态调用方法时为什么重要?
使用 java.lang.reflect.Method 时，候选人常常假设 getDeclaredMethods() 仅返回源级方法。实际上，它包括合成桥接方法，如果不进行过滤，可能导致重复调用或不正确的逻辑。Method 类提供 isBridge() 和 isSynthetic() 谓词来识别这些编译器生成的伪件。未能检查这些标志可能导致无限递归，如果通过反射调用桥接方法，因为它会委托到目标方法，而目标方法可能会在循环中通过反射自己被调用。
为什么非泛型类中的协变返回类型也会生成桥接方法，这与同步修饰符如何交互?
候选人常常忽略桥接方法并不专属于泛型；当在重写方法中缩小返回类型时（协变返回）也会出现。例如，如果父类返回 Number 而子类重写以返回 Integer，则会生成一个返回 Number 的桥接方法。一个关键细节是，synchronized 修饰符从不会复制到桥接方法，因为 JVM 锁将在桥接的帧上获取，而不是实际实现，这可能会破坏线程安全假设。理解这一点需要了解桥接方法仅仅是转发存根，没有自己的同步语义。
当泛型接口方法用变长参数重写时，会发生什么情况，桥接方法在字节码级别如何处理数组与变长参数的区别?
这种情况会创建一个复杂的桥接，其中擦除的签名使用数组类型（Object[]），而实现使用变长参数。编译器生成一个接受 Object[] 的桥接方法，该方法调用变长参数方法。候选人可能会错过变长参数方法在字节码级别上编译为数组参数，因此在描述符上桥接方法与实际方法相同，编译器需要生成额外的逻辑来区分它们或使用 ACC_VARARGS 标志。误解这一点可能会导致分析堆栈跟踪时出现混乱，显示出数组参数而不是变长参数，或者在使用 MethodHandle 调用此类方法时由于描述符匹配的复杂性而引起困惑。