Java的泛型是编译期语法糖，运行时并不存在泛型信息，这一特性被称为类型擦除。当一个类继承或实现了带有泛型参数的父类或接口，并在子类中重写泛型方法时，编译器会在字节码中生成一个额外的synthetic bridge方法（桥接方法），用来保证多态调用在擦除后仍然正确分派。很多开发者会疑惑：明明只写了一个方法，为什么通过反射能拿到两个？@Override注解标注在源码方法上，编译器如何校验重写关系？桥接方法身上又会带上哪些注解？本文从字节码层面逐一拆解这些问题。
类型擦除如何改变方法签名
泛型类或泛型接口在编译后，类型参数会被替换为其上界（无限定时默认为Object）。这意味着一个接收T参数的方法，在字节码层面的描述符会退化为Object。来看一个典型例子：
interface Comparable<T> {
int compareTo(T other);
}
class MyString implements Comparable<String> {
@Override
public int compareTo(String other) {
return 0;
}
}源码层面，子类的compareTo(String)确实重写了接口的compareTo(T)，@Override校验可以通过。但擦除之后，接口方法的实际签名是compareTo(Object)，而子类里只有compareTo(String)，两者签名并不匹配。按照JVM的方法分派规则，通过接口引用调用compareTo时查找的是compareTo(Object)，子类如果没有这个签名，多态就会失效。
为了解决这个矛盾，编译器在编译MyString时会自动生成一个桥接方法，它的签名是compareTo(Object)，内部实现则是对compareTo(String)的强转调用。可以用javap验证：
javap -v MyString.class // 输出片段： // public int compareTo(java.lang.String); // flags: ACC_PUBLIC // public int compareTo(java.lang.Object); // flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC // Signature: (TString;)I
可以看到桥接方法带有ACC_BRIDGE和ACC_SYNTHETIC两个标志位，前者标记它是桥接方法，后者标记它由编译器合成而非源码声明。同时Signature属性保留了泛型签名的元数据，这就是著名的签名属性机制，它让擦除后的字节码仍能通过反射获取泛型信息。
@Override的校验时机与桥接方法的关系
首先要澄清一个常见误解：@Override并不会影响编译器生成桥接方法的决策。桥接方法的生成完全由继承结构决定——只要子类以更具体的类型参数重写了泛型方法，且擦除后签名与父类不一致，编译器就会生成桥接方法，无论你是否写了@Override。
@Override是一个SOURCE保留策略的注解，它只在编译阶段存在，编译完成后不会进入字节码。它的作用是让编译器做一次额外的重写校验：被标注的方法必须重写或实现了父类、接口中的某个方法，否则报编译错误。这个校验发生在类型擦除之前还是之后？答案是校验基于泛型签名进行，即编译器在语义分析阶段比对的是compareTo(String)与Comparable<String>实例化后的compareTo(String)，因此校验能够通过。如果误写成：
class MyString implements Comparable<String> {
@Override
public int compareTo(Integer other) { // 编译错误
return 0;
}
}编译器会直接报错，指出方法没有重写任何东西。这说明@Override的校验是在泛型实例化之后的语义层面完成的，与运行期的类型擦除产物无直接关系。
另一个关键点是桥接方法上的注解情况。JLS规定，编译器生成的桥接方法会复制被重写方法的某些元数据，但@Override由于保留策略是SOURCE，本来就不会出现在任何字节码中，所以讨论它在桥接方法上的存在没有意义。真正值得关注的是RUNTIME策略的注解，例如自定义注解标注在compareTo(String)上时，通过反射获取compareTo(Object)这个桥接方法，默认是读不到该注解的，除非注解本身被@Inherited修饰且满足继承条件。做反射工具开发的读者一定要留意这个坑。
反射场景下的桥接方法行为与实战处理
在反射编程中，桥接方法经常带来意外。典型场景是通过反射遍历类的方法列表做依赖注入或注解扫描时，会发现同一个逻辑方法出现两次，一次是真实方法，一次是桥接方法。如果处理不当，同一个方法会被执行两次，或者注解读取失败。来看一个探测示例：
Method[] methods = MyString.class.getDeclaredMethods();
for (Method m : methods) {
System.out.println(m.getName()
+ " bridge=" + m.isBridge()
+ " synthetic=" + m.isSynthetic());
}
// 输出：
// compareTo bridge=true synthetic=true
// compareTo bridge=false synthetic=false正确的处理方式是先判断isBridge()，对桥接方法通过Method.getGenericParameterTypes()或Spring提供的BridgeMethodResolver.findBridgedMethod()定位到真实的泛型方法，再做后续逻辑。Spring框架在处理@Async、事件监听器等基于注解的方法级功能时，内部大量使用了这套桥接方法解析机制，否则任何带泛型参数的监听器都会失效。
还需要注意桥接方法与反射调用异常的关系。桥接方法内部包含对参数的强制类型转换，如果绕过编译器检查，用反射直接调用桥接方法并传入不匹配的类型，会在运行期抛出ClassCastException，而不是方法签名不匹配的IllegalArgumentException。这是因为桥接方法签名是Object，任何类型都能通过入口检查，真正的类型约束发生在方法体内部的checkcast指令上。这个细节在排查泛型相关的运行时异常时非常有价值。
总结一下核心结论：类型擦除改变了方法的字节码签名，编译器通过桥接方法维持多态正确性；@Override是编译期校验工具，基于泛型实例化后的语义签名判断重写关系，与擦除产物解耦；桥接方法不会继承RUNTIME注解，反射处理时必须显式解析桥接关系。理解这三点，泛型擦除与重写机制的黑盒基本就打开了。
类型擦除桥接方法Override注解修改时间：2026-09-01 12:30:36