天天看点

Java 泛型——类型擦除

输出的结果缘由是类型擦除。

泛型的英文是 generics,generic 的意思是通用,而翻译成中文,泛应该意为广泛,型是类型。所以泛型就是能广泛适用的类型。但泛型还有一种较为准确的说法就是为了参数化类型,或者说可以将类型当作参数传递给一个类或者是方法。

 这就是泛型,它将 value 这个属性的类型也参数化了,这就是所谓的参数化类型。

泛型除了可以将类型参数化外,而参数一旦确定好,如果类似不匹配,编译器就不通过。 

上面代码显示,无法将一个 String 对象设置到 cache2 中,因为泛型让它只接受 Integer 的类型。

总结:

与普通的 Object 代替一切类型这样简单粗暴而言,泛型使得数据的类别可以像参数一样由外部传递进来。它提供了一种扩展能力。它更符合面向抽象开发的软件编程宗旨。

当具体的类型确定后,泛型又提供了一种类型检测的机制,只有相匹配的数据才能正常的赋值,否则编译器就不通过。所以说,它是一种类型安全检测机制,一定程度上提高了软件的安全性防止出现低级的失误。

泛型提高了程序代码的可读性,不必要等到运行的时候才去强制转换,在定义或者实例化阶段,因为 <code>Cache&lt;String&gt;</code> 这个类型显化的效果,程序员能够一目了然猜测出代码要操作的数据类型。

泛型按照使用情况可以分为 3 种。 

1. 泛型类。            2. 泛型方法。                 3. 泛型接口。

1、泛型类

泛型类定义

尖括号 <code>&lt;&gt;</code> 中的 T 被称作是类型参数,用于指代任何类型。事实上,T 只是一种习惯性写法,也你可以这样写。

但出于规范的目的,Java 还是建议我们用单个大写字母来代表类型参数。常见的如: 

1. T 代表一般的任何类。 

2. E 代表 Element 的意思,或者 Exception 异常的意思。 

3. K 代表 Key 的意思。 

4. V 代表 Value 的意思,通常与 K 一起配合使用。 

5. S 代表 Subtype 的意思,文章后面部分会讲解示意。

如果一个类被 <code>&lt;T&gt;</code> 的形式定义,那么它就被称为是泛型类。

泛型类使用

只要在对泛型类创建实例的时候,在尖括号中赋值相应的类型便是。T 就会被替换成对应的类型,如 String 或者是 Integer。你可以相像一下,当一个泛型类被创建时,内部自动扩展成下面的代码。

泛型类也可接受多个类型参数。

2、泛型方法

泛型方法与泛型类稍有不同的地方是,类型参数也就是尖括号那一部分是写在返回值前面的。<code>&lt;T&gt;</code> 中的 T 被称为类型参数,而方法中的 T 被称为参数化类型,它不是运行时真正的参数。声明的类型参数,也是可以当作返回值的类型的。

泛型类与泛型方法的共存现象

上面代码中,<code>Test1&lt;T&gt;</code> 是泛型类,testMethod 是泛型类中的普通方法,而 testMethod1 是一个泛型方法。而泛型类中的类型参数与泛型方法中的类型参数是没有相应的联系的,泛型方法始终以自己定义的类型参数为准。针对上面的代码,可以这样编写测试代码:

泛型类的实际类型参数是 String,而传递给泛型方法的类型参数是 Integer,两者不想干。

但是,为了避免混淆,如果在一个泛型类中存在泛型方法,那么两者的类型参数最好不要同名。比如,<code>Test1&lt;T&gt;</code> 代码可以更改为这样

3、泛型接口

泛型接口和泛型类差不多

除了用 <code>&lt;T&gt;</code> 表示泛型外,还有 <code>&lt;?&gt;</code> 这种形式。? 被称为通配符。

上面代码显示,Base 是 Sub 的父类,它们之间是继承关系,所以 Sub 的实例可以给一个 Base 引用赋值

最后一行代码不会编译通过,Sub 是 Base 的子类,不代表 <code>List&lt;Sub&gt;</code> 和 <code>List&lt;Base&gt;</code> 有继承关系。

但是,在现实编码中,确实有这样的需求,希望泛型能够处理某一范围内的数据类型,比如某个类和它的子类,对此 Java 引入了通配符这个概念。

所以,通配符的出现是为了指定泛型中的类型范围。

通配符有 3 种形式。

<code>&lt;?&gt;</code> 被称作无限定的通配符。

<code>&lt;? extends T&gt;</code> 被称作有上限的通配符。

<code>&lt;? super T&gt;</code> 被称作有下限的通配符。

上面的代码中,方法内的参数是被无限定通配符修饰的 Collection 对象,它隐略地表达了一个意图或者可以说是限定,那就是 testWidlCards() 这个方法内部无需关注 Collection 中的真实类型,因为它是未知的。所以,只能调用 Collection 中与类型无关的方法。

Java 泛型——类型擦除

可以看到,当 <code>&lt;?&gt;</code> 存在时,Collection 对象丧失了 add() 方法的功能,编译器不通过。 我们再看代码:

<code>&lt;?&gt;</code> 提供了只读的功能,也就是它删减了增加具体类型元素的能力,只保留与具体类型无关的功能。它不管装载在这个容器内的元素是什么类型,它只关心元素的数量、容器是否为空?我想这种需求还是很常见的吧。

个人认为引用通配符&lt;?&gt;提高了代码的可读性,别人看到这段代码时,能够迅速对此建立极简洁的印象,能够快速推断源码作者的意图。

<code>&lt;? extends T&gt;</code>

<code>&lt;?&gt;</code> 代表着类型未知,但是我们的确需要对于类型的描述再精确一点,我们希望在一个范围内确定类别,比如类型 A 及 类型 A 的子类都可以。

上面代码中,para 这个 Collection 接受 Base 及 Base 的子类的类型。

但是,它仍然丧失了写操作的能力。也就是说

仍然编译不通过。

<code>&lt;? super T&gt;</code>

这个和 <code>&lt;? extends T&gt;</code> 相对应,代表 T 及 T 的超类。

<code>&lt;? super T&gt;</code> 神奇的地方在于,它拥有一定程度的写操作的能力。

一般而言,通配符能干的事情都可以用类型参数替换。 比如

可以被

取代。

注意:如果用泛型方法来取代通配符,那么上面代码中 collection 是能够进行写操作的。只不过要进行强制转换。

特别注意:类型参数适用于参数之间的类别依赖关系:

E 类型是 T 类型的子类,显然这种情况类型参数更适合。 

有一种情况是,通配符和类型参数一起使用。

如果一个方法的返回类型依赖于参数的类型,那么通配符也无能为力。

泛型是 Java 1.5 版本才引进的概念,在这之前是没有泛型的概念的,但显然,泛型代码能够很好地和之前版本的代码很好地兼容。因为,泛型信息只存在于代码编译阶段,在进入 JVM 之前,与泛型相关的信息会被擦除掉,专业术语叫做类型擦除。

通俗地讲,泛型类和普通类在 java 虚拟机内是没有什么特别的地方。文章开始时的那段代码

打印的结果为 true 是因为 <code>List&lt;String&gt;</code> 和 <code>List&lt;Integer&gt;</code> 在 jvm 中的 Class 都是 List.class。泛型信息被擦除了。

类型 String 和 Integer 进行了泛型转译。

Erasure 是一个泛型类,我们查看它在运行时的状态信息可以通过反射。

打印的结果是

Class 的类型仍然是 Erasure 并不是 <code>Erasure&lt;T&gt;</code> 这种形式,那我们再看看泛型类中 T 的类型在 jvm 中是什么具体类型。

打印结果是

泛型类被类型擦除后,相应的类型就被替换成 Object 类型,这种说法是不完全正确的:

测试结果:

结论:在泛型类被类型擦除的时候,之前泛型类中的类型参数部分如果没有指定上限,如 <code>&lt;T&gt;</code> 则会被转译成普通的 Object 类型,如果指定了上限如 <code>&lt;T extends String&gt;</code> 则类型参数就被替换成类型上限。

所以,在反射中

add() 这个方法对应的 Method 的签名应该是 Object.class。

也就是说,如果你要在反射中找到 add 对应的 Method,你应该调用 <code>getDeclaredMethod("add",Object.class)</code> 否则程序会报错,提示没有这么一个方法,原因就是类型擦除的时候,T 被替换成 Object 类型了。

类型擦除,是泛型能够与之前的 java 版本代码兼容共存的原因。但也因为类型擦除,它会抹掉很多继承相关的特性,这是它带来的局限性。理解类型擦除有利于我们绕过开发当中可能遇到的雷区,同样理解类型擦除也能让我们绕过泛型本身的一些限制。比如

Java 泛型——类型擦除

 正常情况下,因为泛型的限制,编译器不让最后一行代码编译通过,因为类似不匹配,但是,基于对类型擦除的了解,利用反射,我们可以绕过这个限制。

上面是 List 和其中的 add() 方法的源码定义。因为 E 代表任意的类型,所以类型擦除时,add 方法其实等同于

利用反射,我们绕过编译器去调用 add 方法。

打印结果是:

可以看到,利用类型擦除的原理,用反射的手段就绕过了正常开发中编译器不允许的操作限制。

泛型类或者泛型方法中,不接受 8 种基本数据类型。

所以,你没有办法进行这样的编码。

需要使用它们对应的包装类。

对泛型方法的困惑

可能对于连续的两个 T 感到困惑,其实 <code>&lt;T&gt;</code> 是为了说明类型参数,是声明,而后面的不带尖括号的 T 是方法的返回值类型。 

你可以相像一下,如果 test() 这样被调用

那么实际上相当于

这句话可能难以理解,代码:

这两行代码是无法在编译器中编译通过的。原因还是类型擦除带来的影响。

<code>List&lt;Integer&gt;</code> 和 <code>List&lt;Boolean&gt;</code> 在 jvm 中等同于<code>List&lt;Object&gt;</code> ,所有的类型信息都被擦除,程序也无法分辨一个数组中的元素类型具体是 <code>List&lt;Integer&gt;</code>类型还是 <code>List&lt;Boolean&gt;</code> 类型。但是,

借助于无限定通配符却可以,前面讲过 <code>?</code> 代表未知类型,所以它涉及的操作都基本上与类型无关,因此 jvm 不需要针对它对类型作判断,因此它能编译通过,但是,只提供了数组中的元素因为通配符原因,它只能读,不能写。比如,上面的 v 这个局部变量,它只能进行 get() 操作,不能进行 add() 操作,这个在前面通配符的内容小节中已经讲过。

我们可以看到,泛型其实并没有什么神奇的地方,泛型代码能做的非泛型代码也能做。而类型擦除,是泛型能够与之前的 java 版本代码兼容共存的原因。可能也正因为类型擦除导致了一些隐患与局限。但,还是要建议大家使用泛型,如官方文档所说的,如果可以使用泛型的地方,尽量使用泛型。毕竟它抽离了数据类型与代码逻辑,本意是提高程序代码的简洁性和可读性,并提供可能的编译时类型转换安全检测功能。类型擦除不是泛型的全部,但是它却能很好地检测我们对于泛型这个概念的理解程度。