在排查反射框架的重复执行问题时，我遇到过这样一个现象：一个简单的StringHolder类只声明了一个getValue方法，但通过getDeclaredMethods打印方法列表时却出现两个同名方法。进一步查看方法返回类型，一个是String，另一个是Object。起初怀疑是编译缓存或IDE生成问题，排查后确认这是Java编译器为泛型擦除自动生成的桥接方法。桥接方法在源码中不可见，却真实存在于字节码，直接影响反射调用和框架扫描逻辑。
一、桥接方法从哪里来：泛型擦除与返回类型协变
Java泛型在编译后会被擦除。比如接口 Holder<T> 中的 T getValue()，编译后签名会变成 Object getValue()。如果子类 StringHolder 实现 Holder<String> 并覆盖为 String getValue()，那么从Java源码看，这像是返回类型协变的重写，方法签名发生了变化；但在JVM层，方法描述符包含返回类型，String getValue() 和 Object getValue() 是两个不同的方法。
为了维持多态，编译器会为子类生成一个桥接方法。它通常长这样：
public interface Holder<T> {
T getValue();
}
public class StringHolder implements Holder<String> {
@Override
public String getValue() {
return "hello";
}
}
以上源码编译后，StringHolder 的字节码中会存在两个方法：一个是返回 String 的真实方法，另一个是返回 Object 的桥接方法。桥接方法内部不做复杂处理，只是把 this 强转后调用真实方法并返回结果。可以把它理解成JVM为了兼容父接口声明而自动补上的适配层。
桥接方法不只出现在接口实现中。只要子类继承或实现了一个泛型父类型，并且重写后的方法签名因为泛型擦除无法与父类型签名完全一致，编译器就可能在子类中生成桥接方法。比如父类声明 Object getValue()，子类声明 String getValue()，从Java源码看是合法的返回类型协变，但字节码里它们就是两个方法。为了保证调用父类方法时仍然能命中子类逻辑，编译器生成了以 Object 为返回类型的桥接方法。
这些编译器生成的方法在字节码层面带有 ACC_BRIDGE 和 ACC_SYNTHETIC 标志。前者说明它用于桥接父类签名，后者说明它不是源码中显式声明的成员。这两个标志正是后面识别和过滤桥接方法的重要依据。
二、getDeclaredMethods 为什么返回重复方法名
Java反射中 getDeclaredMethods 返回类自身声明的所有方法，包括编译器生成的方法。由于桥接方法也在 declared 范围内，于是出现同名现象。例如上述 StringHolder 会返回两个名为 getValue 的方法：一个返回 java.lang.String，一个返回 java.lang.Object。两者参数列表都为空，仅返回类型不同。Java语言不允许仅靠返回类型重载，但JVM允许方法描述符不同。
用反射打印可以清楚看到：
for (Method method : StringHolder.class.getDeclaredMethods()) {
System.out.println(method.getName());
System.out.println("return=" + method.getReturnType().getName());
System.out.println("bridge=" + method.isBridge());
System.out.println("synthetic=" + method.isSynthetic());
System.out.println("---");
}
输出中，两个方法名都是 getValue。其中一个 isBridge() 为 true，return 是 Object；另一个 isBridge() 为 false，return 是 String。需要注意的是，如果调用 getDeclaredMethod("getValue")，JDK内部按名称和参数类型查找，并不区分返回类型。当存在多个候选时，返回哪一个取决于底层实现，容易造成不稳定。更安全的方式是获取全部方法后按返回类型和桥接标志过滤。
这个现象在框架中可能被放大。比如AOP切面根据方法名匹配，两个同名方法都会命中，导致同一个业务动作触发两次增强；再比如基于方法名加参数类型做缓存键，桥接方法和真实方法会映射到同一键，但得到的Method对象不同，轻则命中异常，重则反射调用时抛出NullPointerException或IllegalArgumentException。排查时如果不看 isBridge() 标志，往往会误判为代码重复。
三、识别桥接方法并设计稳定的过滤器
处理重复方法名的第一步是识别桥接方法。Method 提供了 isBridge() 和 isSynthetic() 两个方法。桥接方法通常同时满足这两个条件：它由编译器合成，并且是为了桥接父类签名而存在。可以写出如下过滤方法：
public static List<Method> getBusinessMethods(Class<?> clazz) {
List<Method> methods = new ArrayList<>();
for (Method method : clazz.getDeclaredMethods()) {
if (method.isBridge() || method.isSynthetic()) {
continue;
}
int mod = method.getModifiers();
if (Modifier.isPublic(mod) || Modifier.isProtected(mod)) {
methods.add(method);
}
}
return methods;
}
这里把 isBridge() 和 isSynthetic() 一起排除，是因为合成方法除桥接外还包括其他编译器生成的结构，比如某些内部类访问外部私有成员时生成的 access$xxx 方法。反射调用框架通常只需要业务代码声明的方法，因此两个条件放在一起过滤更稳妥。
但只过滤还不够，因为有时父类或接口的方法也需要参与调用。例如通过接口引用执行方法时，应该选择接口声明的方法，还是实现类的真实方法？这取决于调用目标。如果按实现类扫描，建议保留非桥接、非合成方法，并优先选择返回类型更具体的那个。可以通过比较 method.getReturnType().isAssignableFrom(other.getReturnType()) 来识别。或者使用 method.equals() 进行精确身份判断，但跨类返回的 Method 对象不完全相同，需要先确认目标来源。
稳定的反射调用不能只依赖方法名。一个可用的键应当包含方法名、参数类型以及返回类型，或者在获取到唯一候选 Method 后直接保存 Method 对象本身。这样可以避免同名方法覆盖缓存。
四、反射调用优化：缓存真实方法并避免桥接转发
反射调用框架最常见的性能优化就是缓存 Method 对象，避免每次调用都重新查找。但如果缓存到了桥接方法，会带来额外开销：桥接方法内部通常会再调用真实方法，反射调用桥接方法时等于执行了两层方法入口。对于高并发场景，这层额外转发虽然不是最大的性能瓶颈，但会放大栈深度，并对一些基于方法对象的切面逻辑产生干扰。
可以设计如下缓存结构，将过滤和缓存合并：
private static final Map<String, Method> METHOD_CACHE = new ConcurrentHashMap<>();
public static Method resolve(Class<?> clazz, String methodName, Class<?>... paramTypes) {
String key = clazz.getName() + "#" + methodName + "(" + Arrays.toString(paramTypes) + ")";
Method cached = METHOD_CACHE.get(key);
if (cached != null) {
return cached;
}
for (Method method : clazz.getMethods()) {
if (!method.getName().equals(methodName)) {
continue;
}
if (!Arrays.equals(method.getParameterTypes(), paramTypes)) {
continue;
}
if (method.isBridge() || method.isSynthetic()) {
continue;
}
METHOD_CACHE.put(key, method);
return method;
}
throw new NoSuchMethodException("no business method: " + methodName);
}
上面的逻辑优先遍历 getMethods() 获取公共方法，并跳过桥接方法。缓存键包含类名、方法名和参数类型数组，必要时可以增加返回类型描述，以应对极少数同名不同返回类型的桥接场景。实际项目中更推荐使用 ConcurrentHashMap 保存 Method，并在启动预热阶段完成解析，避免运行时并发首次查找。
另一种优化思路是直接从接口层解析。比如框架只暴露接口，可以通过 clazz.getInterfaces() 获取接口声明的方法，这些方法通常不会包含编译器为实现类生成的桥接方法。然后在接口 Method 上调用 invoke(implInstance, args)，JVM会按动态分派找到具体实现。这样既能避免桥接方法，又能保持抽象调用的一致性。不过要注意，如果接口本身继承多个父接口，仍可能出现同签名但返回类型协变的方法，需要按相同规则过滤。
对于已经缓存了大量 Method 对象的系统，想要快速清理桥接方法，可以用 method.isBridge() 做一次启动扫描，将桥接方法从缓存中移除并记录日志。这样不必改动调用主链，只需修复缓存初始化部分。定位问题时，可以反编译 class 文件查看 ACC_BRIDGE 标志，也可以直接使用 JDK 自带的 javap -v 查看方法签名，避免凭源码猜测。
桥接方法本身不是缺陷，它是Java泛型兼容的底层机制。反射优化要做的不是对抗它，而是识别它、绕开它，并在缓存设计时把它排除在业务方法集合之外。这样既能消除 getDeclaredMethods 返回重复方法名带来的干扰，也能减少不必要的反射转发，让框架调用链更清晰。
桥接方法getDeclaredMethods反射调用优化修改时间：2026-10-03 03:40:42