桥接方法在vtable中与父类/接口方法共享同一槽位，确保invokevirtual以o(1)完成分派；其本质是签名适配的转发方法，不增加查找开销，但引入运行时转型代价。
桥接方法在 vtable 中的位置不是随意安排的，它直接关系到 invokevirtual 指令能否以 O(1) 时间完成方法分派。理解这一点，就能看清泛型擦除后多态调用的真实开销来源。
桥接方法如何进入 vtable
当泛型类（如 List
public Object get(int i) { return (String) this.get(i); }
这个桥接方法会被当作一个“真实重写方法”纳入子类（如 ArrayList）的 vtable，占据与父类接口中对应方法（List.get）相同的槽位索引。它不额外增加查找层级，也不改变 vtable 结构——只是在该槽位填入一个强制转型后转发的字节码入口。
关键点在于：桥接方法和它所桥接的目标方法（如 ArrayList.get(int)）共享同一个 vtable 索引。JVM 查找时仍走固定偏移，没有遍历、没有反射解析、不依赖运行时类型判断。
为什么不能跳过桥接方法直接调用子类真实方法
即便你知道子类有更具体的实现（比如 ArrayList.get(int): String），也不能通过反射绕过桥接方法去“直连”它，原因很底层：
- JVM 的 invokevirtual 指令只认符号引用签名（类名+方法名+描述符），而桥接方法的签名是 (I)Ljava/lang/Object;，真实方法是 (I)Ljava/lang/String; —— 描述符不同，根本不在同一个 vtable 槽位
- vtable 是按声明顺序静态构建的，每个槽位只存一个函数指针；即使子类定义了多个同名但签名不同的方法，也只有符合父类/接口签名的那个能进表
- 反射调用（如 Method.invoke()）走的是解释执行路径，不利用 vtable，性能远低于 invokevirtual，且无法规避桥接逻辑
桥接方法对性能的实际影响
桥接方法本身引入的开销极小，通常只是一条类型检查 + 强制转型 + 方法转发指令。它的存在不改变 invokevirtual 的 O(1) 查表本质，也不触发额外的虚方法查找流程。
真正影响性能的，是桥接方法背后的语义代价：
- 返回值需要运行时转型（如 (String)），可能引发 ClassCastException，而该异常在编译期无法捕获
- 如果目标方法被 JIT 内联，桥接方法也可能被一起内联，此时转型操作可被优化掉；但如果因泛型擦除导致类型信息丢失，JIT 可能保守地保留转型检查
- 大量使用泛型集合时，桥接方法虽不拖慢分派，但会略微增加方法体长度和寄存器压力，对热点代码的优化边界有细微影响
实战观察桥接方法在 vtable 中的位置
可通过以下方式验证桥接方法是否如预期占据 vtable 槽位：
- 用 javap -v 查看字节码，确认桥接方法带有 ACC_BRIDGE | ACC_SYNTHETIC 标志
- 借助 HotSpot 调试工具（如 hsdis 或 JFR 的 method profiling）观察 invokevirtual 调用是否命中同一地址（即同一 vtable 槽位）
- 对比 ArrayList
.get() 和原始类型 ArrayList.get() 的调用路径：前者经桥接方法转发，后者直接调用，但两者 invokevirtual 查表步骤完全一致
