导读 | 笔者在最近的日常工作中,因业务需要,研究 Java 字节码层面的知识。具体是,需要根据类字节码,获取特定方法名的方法入参,此方法名在源码中只有一个。但是在实际使用中发现:在类实现泛型接口的情况下,在字节码层面,类却有两个同名方法,导致无法确定哪个方法才是我们需要的方法。经过研究发现,其中一个方法是编译器在编译的过程中,自动生成的桥接方法(bridge method),两个方法可通过特定标识区分。 |
注:此处的桥接方法,跟设计模式中的桥接模式,不是一个概念。
为了能够说明问题,笔者模糊了实际业务场景的具体案例,用一个稍微简单,能够说明问题的示例,来分析编译器自动生成的桥接方法(bridge method)。
我们知道,Java 泛型是JDK 5 中引入的一个新特性,应用广泛。比如,我们有一个操作算子泛型接口 Operator,接口中有一个 process(T t) 方法,其作用是对入参 T 进行逻辑处理。示例代码如下:
/** * @author renzhiqiang * @date 2022/2/20 18:30 */ public interface Operator { /** * process method * @param t */ void process(T t); }
在实际业务场景中,我们会有不同的操作算子,实现Operator 接口,进行业务逻辑处理。那么我们来创建一个具体的算子,并实现Operator 接口,重写 process(T t) 方法。如下:
/** * 用户信息算子 * @author renzhiqiang * @date 2022/2/20 18:30 */ public class UserInfoOperator implements Operator { @Override public void process(String s) { // do something } }
其中,泛型接口中的入参类型 T,在实现类中替换成了实际需要的类型 java.lang.String。到这里,我们就准备好了代码样例。
那么,我们的目标是什么呢?就是要获取UserInfoOperator#process(String s) 方法的参数类型java.lang.String。读到这里,读者可能会想:这不很简单么,通过反射,根据Class#getDeclaredMethods(),获取到 UserInfoOperator 的所有方法,再找到方法名是 process 的方法,然后再获取到参数列表,不就可以获取参数类型java.lang.String 了么。
如果正在阅读文章的你也这么想的话,那请继续往下看。
根据 Java 反射方法Class#getDeclaredMethods() 的描述:
Returns an array of Method objectsincluding public, protected, default (package) access, and private methods, butexcludes inherited methods.
翻译过来就是:返回方法对象数组,包括公共方法、受保护方法、默认(包)访问方法和私有方法,但不包括继承方法。
根据我们的示例,如果我们通过反射,利用Class#getDeclaredMethods() 方法,我们预期的返回方法数组中,应该只有一个方法名是process 才对,但是这里却有两个 process 方法。惊不惊奇,意不意外!
我们知道,Java 源码需要经过编译器编译,生成对应的 .class 文件,才能给 JVM 使用。在源码中,我们只定义了一个名为 process 的方法。那么我们考虑,编译器在编译源码的过程中,是否会进行一些特的处理。为了更加直观的查看编译后的字节码文件,在 Idea 安装 jclasslib 插件,通过 jclasslib 查看 UserInfoOperator 和 Operator 的字节码。如下:
通过 jclasslib 查看 .class 文件发现,在 UserInfoOperator 类中确实存在两个 process 方法:其中一个方法入参是 java.lang.String,另一个方法的入参是 java.lang.Object。而在 Operator 字节码中,只有一个 process 方法,方法的入参是 java.lang.Object。同时我们注意到,在 UserInfoOperator 类的字节码中, [访问标志]项,其中一个方法的访问标志是 [public synthetic bridge]。其中 public 很好理解,但是其中的 [synthetic bridge] 是怎么来的呢?
查阅相关资料后发现,标识符 synthetic ,表示此方法是否是由编译器自动产生的;标识符 bridge,表示此方法是否是由编译器产生的桥接方法。
到此,可以确定的是,其中一个process 方法,是编译器自动产生的桥接方法。那么为什么编译器会产生桥接方法呢?以及在什么情况下,会产生桥接方法?以及如何判断一个方法是不是桥接方法?我们继续往下分析。
在源码中,Operator 类的 process 方法的参数定义是 process(T t),参数类型是 T。而在字节码层面我们看到,process 方法在编译之后,编译器将入参类型变成了 java.lang.Object。伪代码示意,大概是这样:
public interface Operator
想象一下,如果没有编译器自动生成的桥接方法,那么在编译层面是不能通过的:因为接口 Operator 中的 process 方法,,经过编译之后,参数类型变成了 java.lang.Object 类型,而实现类 UserInfoOperator 中的 process 方法的参数是 java.lang.String 类型,两者的方法参数不一致,导致UserInfoOperator 并没有重写接口中的 process 方法,因此编译无法通过。
这种情况下,编译器自动生成一个桥接方法 void process(Object obj) 方法,则可以编译通过,似乎是理所当然的事情。自动生成的 process方法,方法签名为:void process(Object object)。伪代码示意,大概是这样:
// 自动生成的process 方法 public void process(Object object) { process((String) object); }
我们知道,Java 中的泛型在编译期间会将泛型信息擦除。如代码定义 List 和 List,编译之后都会变成 List。我们再考虑一种常见的情形:Java 类库中比较器的用法。我们自定义比较器的时候,可以通过实现 Comparator 接口,实现比较逻辑。示例代码如下:
public class MyComparator implements Comparator{ public int compare(Integer a,Integer b) { // 比较逻辑 } }
这种情况下,编译器同样会产生一个桥接方法。方法签名为 intcompare(Object a, Object b) 。
伪代码示意,大概是这样:
public class MyComparator implements Comparator{ public int compare(Integer a,Integer b) { // 比较逻辑 } // 桥接方法 (bridge method) public int compare(Object a,Object b) { return compare((Integer)a,(Integer)b); } }
因此,当我们使用如下方式进行比较的时候,能够通过编译并得到我们预期的结果:
Object a = 5; Object b = 6; Comparator rawComp = new MyComparator(); // 可以通过编译,因为自动生成了桥接方法compare(Object a, Object b) int comp = rawComp.compare(a, b);
另外,我们知道,泛型编译之后,类型信息会被擦除。如果我们有这样一个比较方法:
// 比较方法 publicT max(List list, Comparator comparator){ T biggestSoFar = list.get(0); for ( T t : list ) { if (comparator.compare(t,biggestSoFar) > 0) { biggestSoFar = t; } } return biggestSoFar; }
编译之后,泛型被擦除掉,伪代码表示,大概是这样:
public Object max(List list, Comparator comparator) { Object biggestSoFar =list.get(0); for ( Object t : list ) { if (comparator.compare(t,biggestSoFar) > 0) { //比较逻辑 biggestSoFar = t; } } return biggestSoFar; }
我们将 MyComparator 其中一个参数传入 max() 方法。如果没有桥接方法的话,那么第四行的比较逻辑,将无法正确编译,因为MyComparator 类中没有两个参数是 Object 类型的比较方法,只有参数类型是 Integer 类型的比较方法。读者可自行测试。
通过以上的案例描述,我们知道,在实现泛型接口的场景下,编译器会自动生成桥接方法,保证编译能够通过。那么在这种情况下,我们只要识别哪一个是桥接方法,哪一个不是桥接方法,就可以解决我们一开始的问题。很自然的,既然编译器自动产生了一个桥接方法,那么应该会有某种方式,可以让我们判断一个方法是否是桥接方法。
果然,我们继续研究发现,Method 类中提供了 Method#isBridge() 方法。查看源码中对方法的描述:Method#isBridge():Returns true if this method is a bridge method;returns false otherwise。
到此,我们通过反射,获取到 UserInfoOperator 类中的两个process 方法,再调用 Method#isBridge() 方法,即可锁定需要的方法,因而进一步获取方法参数 java.lang.String。
至此可以说,就业务需求来说,我们完美的找到了解决方案。但在此之后,不禁会想:除了上述示例,还有哪些情况下,编译器也会自动生成桥接方法呢?我们继续深入研究。
通过查阅相关资料,我们考虑如下一种情况:
/** * 如下会产生桥接方法吗? * @author renzhiqiang * @date 2022/2/20 18:33 */ public class BridgeMethodSample { static class A { public void foo() { } } public static class C extends A{ } public static class D extends A{ @Override public void foo() { } } }
上述代码示例中,我们定义了三个静态内部类:A C D,其中 C D 分别继承 A。经过编译,通过jclasslib 查看 BridgeMethodSample 字节码,我们也发现:类 C 中编译器为其生成了桥接方法 void foo(),而类 D 中却没有。
深入分析,并根据上述分析的经验,我们猜测,编译器生成桥接方法,一定是在某种情况下需要一个方法,来满足 Java 编程规范,或者需要保证程序运行的正确性。通过字节码可以看出,类 A 没有 public 修饰,包范围以外的程序是没有访问类 A 的权限的,更不用说类 A 中的方法。
但是类 C 是有public 修饰,C 类中的方法,包括继承来的方法,是可以被包外的程序访问的。因此,编译器需要生成一个桥接方法,以保证能够访问 foo() 方法,满足程序的正确运行。但是,类 D 同样继承 A,却没有生成桥接方法,根本原因是类 D 中重写了父类 A 中的 foo() 方法,即没有必要生成桥接方法。
我们再看一种情况,方法重写。
Java 中,方法重写(Override),是子类对父类的允许访问的方法的实现过程进行重新编写的过程。重写需要满足一定的规则:
- 1. The method must have the same name as in the parentclass.
- 2. The method must have the same parameter as in theparent class.
- 3. There must be an IS-A relationship (inheritance).
JDK 5 之后,重写方法的返回类型,可以与父类方法返回类型相同,也可以不相同,但必须是父类方法返回类型的子类。我们考虑如下代码示例:
// 定义一个父类,包含一个 test() 方法 public class Father { public Object test(String s) { return s; } } // 定义一个子类,继承父类 public class Child extends Father { @Override public String test(String s) { return s; } }
以上,在 Child 子类中,我们重写了 test() 方法,但是返回值的类型,我们将 java.lang.Object 改变为它的子类 java.lang.String。编译之后,我们同样使用 jclasslib 插件,查看两个类的字节码,如下所示:
根据上图我们发现,Child 类中我们重写了 test() 方法,但是在字节码层面,发现有两个 test() 方法,其中一个方法的访问标志为 [public synthetic bridge], 表示这个方法是编译器为我们生成的。而当我们不改变 Child#test() 方法的返回类型时,编译器并没有为我们生成桥接方法,读者可自行试验。
也就是说,在子类方法重写父类方法,返回类型不一致的情况下,编译器也为我们生成了桥接方法。
以上,笔者罗列了几种编译器为我们自动生成桥接方法的情况。那么是否还有其他场景下,编译器也会生成桥接方法呢?如果您也曾研究过或者使用过 bridge 方法,欢迎交流讨论。
原文来自:
本文地址://q13zd.cn/java-bridge-method.html编辑:KSJXAXOAS,审核员:逄增宝
Linux大全:
Linux系统大全: