Java中的泛型与桥接方法

发布时间:2024年01月11日

1.泛型

泛型是一种编程范式,在不同的语言和编译器中的实现和支持方式都不一样。
通常情况下,一个编译器处理泛型有多种方式,以C++和Java的编译器为例展开介绍
C++中,当编译器对以下代码进行编译时:

template<typename T>
struct Foo {
	T bar;
	void doSth(T param) {
	}
}

Foo<int> f1;
Foo<float> f2;

编译器发现要用到Foo和Foo,这时就会为每个泛型类新生成一份执行代码,相当于新创建了如下两个类:

struct FooInt {
	int bar;
	void doSth(int param) {
	}
}

struct FooFloat {
	float bar;
	void doSth(float param) {
	}
}

这种做法很方便,只需要根据具体类型找到具体的类和方法即可,但问题是,当我们多次使用不同类型的模板时,就会创建很多新的类,导致代码膨胀

Java在处理泛型时,采用了另外一种方式。Java的编译器在编译以下代码时:

public class Foo<T> {
	T bar;
	void doSth(T param) {
	}
}

Foo<String> f1;
Foo<Integer> f2;

并不会创建多份执行代码,在编译后的字节码文件中会把泛型的信息擦除:

public class Foo {
	Object bar;
	void doSth(Object param) {
	}
}

也就是说,代码中的Foo<Integer>和Foo<String>使用的类经过编译后都是同一个类。
所以说泛型技术实际上是Java语言的一颗语法糖,因为泛型经过编译器处理之后就被擦出了,编译器根本不认识泛型,这种擦除过程被称为类型擦除。
类型擦除指的是通过类型参数合并,将泛型类型实例关联到同一份字节码上。编译器只为泛型类型生成一份字节码,并将其实例关联到这份字节码上,类型擦除的关键在于从泛型类型中清除类型参数的相关信息,并在必要时添加类型检查和类型转换的方法
类型擦除可以简单理解为将泛型Java代码转换为普通Java代码,只不过编译器更直接,将泛型代码直接转换成普通Java字节码

1.1 在泛型为String的List中存放Integer对象

既然在代码编译之后,泛型的类型都被擦除了,是不是可以意味着我们可以在一个泛型为String的List中存放Integer对象了呢?
反射技术可以帮我们实现这个功能

package other;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

/**
 * @author xieh
 * @date 2024/01/08 21:59
 */
public class Main {
    public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException,
            IllegalAccessException {
        // 定义一个泛型为String的ArrayList
        List<String> stringList = new ArrayList<>();
        //向List中正常添加String对象
        stringList.add("cover");
        stringList.add("vinpink");

        // 利用反射技术获取List的add方法
        Method method = stringList.getClass().getMethod("add", Object.class);
        // 向List中添加一个Integer对象
        method.invoke(stringList, new Integer(2222));
        // 遍历输出List中的元素
        Iterator iterator = stringList.iterator();
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }

    }
}

代码输出如下
在这里插入图片描述
之所以可以这样做,是因为反射是一种运行期的技术,类型会在编译期被擦除,所以到了运行期,这个List是可以接收任何类型的对象的

2.桥接方法

在某些情况下,基本类型擦除会导致方法重写的问题,为了防止出现这种情况,Java编译器有时会生成桥接方法。问题来了,什么是桥接方法?

public interface Parent<T> {
	public void set(T t);
}

接着定义一个类实现Parent类,并指向泛型类型为String

public class Child implements Parent<String> {

    @Override
    public void set(String s) {
        System.out.println("child");
    }
}

在上面的代码中,Child中的set方法实现并重写了Parent中的set方法
到那时,泛型在编译之后就会被类型擦除,Parent中的set(T t)会被擦除编程set(Object t),这与Child中的set(String s) 方法具有不同的参数类型,那么就不是方法重写,而是方法重载了。
问题来了,Child类实现了Parent接口,但是并没有实现其中的set(Object t)方法,这是怎么回是?
其实,这个问题在泛型设计之初就被考虑到了,编译器通过Child类中插入一个桥接方法set(Object t) 来解决这个问题,
我们把Child编译成class文件,再使用jad工具反编译成Java文件,得到如下内容

public class Child
    implements Parent
{

    public Child()
    {
    }

    public void set(String s)
    {
        System.out.println("child");
    }

    public volatile void set(Object obj)
    {
        set((String)obj);
    }
}

在Child类中,JVM自动帮我们生成了一个set(Object obj)方法,并且调用了set(String s) 方法,这个set(Object obj)方法就是桥接方法
所以当一个字类在继承(或实现)一个父类(或接口)的泛型方法时,在字类中明确指定了泛型类型,编译器为了让字类有一个与父类的方法签名一致的方法,就会在子类中自动生成一个与父类的方法签名一致的桥接方法

我们再来稍微改一下

public interface Parent<T> {
//    public void set(T t);
    public T get();
}

```java
public class Child implements Parent<String> {
    @Override
    public String get() {
        return null;
    }

//    @Override
//    public void set(String s) {
//        System.out.println("child");
//    }

}

在接口和类中定义了带有返回值的get方法,根据前面的桥接方法规则,JVM会在编译过程中向Child添加一个返回值为Object的get方法,得到Child类如下

// Referenced classes of package other:
//            Parent

public class Child
    implements Parent
{

    public Child()
    {
    }

    public String get()
    {
        return null;
    }

    public volatile Object get()
    {
        return get();
    }
}

Child类中有两个get方法,相同的方法名,相同的参数列表,只是返回值不同,这是怎么做到的?
是不是颠覆了认知?因为哦我们时永远不可能在代码中定义两个相同名称且具有相同数量和类型参数的方法的
我们不可以,但是编译器可以
之所以可以这样做,是因为在Java虚拟机中,方法是通过它的名称、参数的数量和类型以及它的返回类型来定义的,所以,返回值不同也是两个方法,这也是桥接方法可以存在的一个重要原因

文章来源:https://blog.csdn.net/Cover_sky/article/details/135467049
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。