反射调用桥接方法比直接调用慢10–80倍，因反射需额外权限检查、参数数组分配及无法优化的强制转型，而桥接方法本身仅纳秒级开销；行为通常一致，但getDeclaringClass()返回实现类且SecurityManager可能拦截反射调用。
反射调用桥接方法（bridge method）和直接调用桥接方法，在行为上通常一致，但在性能上有显著差距——反射调用会额外承担桥接方法本身带来的开销，再叠加反射固有的运行时成本，整体延迟比直接调用高数倍至数十倍。
什么是桥接方法？
桥接方法是编译器为支持泛型类型擦除而自动生成的合成方法。例如在泛型接口实现类中：
interface Processor<T> { void handle(T item); }
class StringProcessor implements Processor<String> {
public void handle(String s) { ... } // 实际实现
}
// 编译后，javac 会生成一个桥接方法：
public void handle(Object o) { handle((String) o); } // 桥接方法，签名擦除后需兼容原始类型
这个桥接方法在字节码中被标记为 ACC_BRIDGE | ACC_SYNTHETIC，对开发者透明，但 JVM 和反射 API 都能识别它。
直接调用桥接方法的实际效果
你几乎不会“直接调用”桥接方法，因为它的签名（如 handle(Object)）通常不暴露在源码中，IDE 和编译器会自动绑定到你写的泛型方法（如 handle(String)）。JVM 在调用时通过虚方法表（vtable）直接分派到目标实现，全程无额外类型转换开销（JIT 还可能内联优化）。
立即学习“Java免费学习笔记（深入）”；
- 调用路径短：字节码指令直接 invokevirtual → 目标方法
- 类型安全由编译器保障，运行时不需强制转型
- JIT 可对其执行逃逸分析、内联、常量传播等优化
反射调用桥接方法会触发双重开销
当你通过反射获取并调用一个桥接方法（比如 getMethod("handle", Object.class)），实际发生的是：
- 反射先按签名匹配到桥接方法（而非你源码里写的那个泛型方法），因为桥接方法才是字节码中真实存在的
Object参数版本 - invoke() 执行时仍要走完整的反射链路：权限检查、参数数组堆分配、装箱/拆箱（若传基本类型）、MethodAccessor 分派
- 桥接方法自身还要做一次向下转型（
(String) o），这步在反射调用中无法被 JIT 优化掉，变成每次必做的运行时 cast - 如果未缓存 Method 对象，每次查找还会重复解析方法符号、遍历 declared methods 列表
性能差距实测表现
以百万次调用空泛型方法为例（JDK 17，预热充分，GC 平稳）：
- 直接调用泛型方法（编译器自动绑定到桥接逻辑）：≈ 5–8 ms
- 反射调用桥接方法（缓存 Method + setAccessible(true)）：≈ 60–120 ms（慢 10–20 倍）
- 反射调用桥接方法（未缓存，每次 getMethod）：≈ 200–400 ms（慢 40–80 倍）
注意：桥接方法本身比普通方法略慢（因多一次强制转型），但该差异仅纳秒级；真正拉大差距的是反射机制的结构性开销，而非桥接逻辑本身。
行为差异虽小，但需警惕
绝大多数场景下，反射调用桥接方法与直接调用行为一致。但以下情况可能暴露差异：
- 桥接方法的
getDeclaringClass()返回的是实现类（如StringProcessor.class），而非接口；直接调用时你感知不到这个细节 - 若桥接方法被
SecurityManager拦截（已废弃但部分老环境仍启用），反射调用会触发额外权限校验，而直接调用不会 - 使用
MethodHandle替代Method.invoke()可绕过部分反射开销，但它仍需显式指向桥接方法——若误取了非桥接的泛型签名方法，会抛NoSuchMethodException
