泛型擦除后子类重写方法仍能多态调用，靠编译器生成的桥接方法实现：它签名与父类擦除后方法一致，内部转发至实际方法，并标记为synthetic和bridge以维持jvm重写关系。
泛型擦除后，子类重写方法怎么还能多态调用
Java泛型在编译期被擦除，ArrayList<string></string> 和 ArrayList<integer></integer> 运行时都是 ArrayList。但你写 new ArrayList<string>().add("a")</string>，调用的是 add(String)；而如果子类重写了泛型方法，比如 class MyList extends ArrayList<string></string> 里重写 add(String)，JVM 怎么确保父类引用调用时走的是子类版本？靠桥接方法。
编译器在生成字节码时，会为存在泛型类型擦除冲突的重写方法，自动生成一个「桥接方法」——它签名与父类方法一致（保留擦除后的原始类型），但内部只是转发给你的实际实现方法。
- 桥接方法是
synthetic的，不会出现在源码里，但javap -c能看到 - 它由编译器强制插入，不是你写的，也不能手动覆盖或删除
- 反射中调用
Method.isBridge()可以识别它
为什么 javac 必须生成桥接方法
不生成桥接方法，多态就断了。比如：
interface Processor<T> {
void process(T item);
}
class StringProcessor implements Processor<String> {
public void process(String s) { ... }
}
编译后，Processor.process 擦除为 process(Object)，而你的 StringProcessor.process(String) 擦除为 process(String) ——这在 JVM 看来是两个不同签名的方法，无法构成重写。JVM 方法表匹配失败，父接口引用调用就会报 NoSuchMethodError 或直接走 Object 版本。
立即学习“Java免费学习笔记（深入）”；
- 桥接方法补全了「重写关系」：编译器自动加一个
public void process(Object x) { this.process((String)x); } - 这个方法被标记为
bridge和synthetic，让 JVM 认为它确实重写了父类/接口方法 - 没有它，泛型接口实现类根本无法通过多态向上转型使用
桥接方法常见错误现象和排查方式
你一般不会直接看到「桥接方法」报错，但它的存在会引发几类典型问题：
-
java.lang.NoSuchMethodError：发生在运行时，尤其是混合使用不同 JDK 编译的库时（如 JDK 8 编译的泛型类被 JDK 17 反射调用），可能因桥接方法生成策略微调导致签名不匹配 - 反射调用失败：用
clazz.getDeclaredMethod("process", Object.class)找到的是桥接方法，但你误以为是业务方法，强转参数或调用时报ClassCastException - Mockito 等框架 mock 泛型类时抛
MockitoException：因为它默认忽略bridge方法，却试图拦截业务方法，结果找不到可代理的目标 - IDE 显示方法被「重载而非重写」：光标放上去提示「method does not override method from supertype」，其实是 IDE 解析没考虑桥接逻辑，不代表代码错
桥接方法对性能和兼容性的影响很小，但别依赖它写逻辑
桥接方法本质是一层极轻量的跳转（一次类型检查 + 一次 invokevirtual），JIT 很快就能内联，几乎无开销。但它不是语言特性，而是编译器补丁，有几点必须注意：
- 不能在源码里声明
bridge或synthetic方法，JVM 会拒绝加载 - 不要在注解处理器或字节码操作（如 ASM）中假设桥接方法一定存在——某些简化编译路径（如
-XDignore.symbol.file）可能影响其生成 - Android D8/R8 默认保留桥接方法，但启用完整优化后可能合并或移除，若用反射+泛型做插件机制，需加
@Keep保护桥接方法所在的类
真正容易被忽略的是：桥接方法只解决「方法签名层面」的重写一致性，它不解决泛型类型信息丢失带来的运行时类型安全问题。比如 List<string></string> 仍能 add(Integer)，桥接方法拦不住——那是类型擦除本身决定的，不是桥接能补的。
