Java泛型

Java泛型由来的动机

理解Java泛型最简单的方法是把它看成一种便捷语法，能节省你某些Java类型转换(casting)上的操作：

List<Apple> box = new ArrayList<Apple>();
Apple apple = box.get(0);

 

上面的代码自身已表达的很清楚：box是一个装有Apple对象的List。get方法返回一个Apple对象实例，这个过程不需要进行类型转换。没有泛型，上面的代码需要写成这样：

 List box = new ArrayList() ;
 Apple apple = (Apple) box.get(0); 

 

很明显，泛型的主要好处就是让编译器保留参数的类型信息，执行类型检查，执行类型转换操作：编译器保证了这些类型转换的绝对无误。

相对于依赖程序员来记住对象类型、执行类型转换——这会导致程序运行时的失败，很难调试和解决，而编译器能够帮助程序员在编译时强制进行大量的类型检查，发现其中的错误。

泛型的构成

由泛型的构成引出了一个类型变量的概念。根据Java语言规范，类型变量是一种没有限制的标志符，产生于以下几种情况：

• 泛型类声明
• 泛型接口声明
• 泛型方法声明
• 泛型构造器(constructor)声明

 

泛型类和接口

如果一个类或接口上有一个或多个类型变量，那它就是泛型。类型变量由尖括号界定，放在类或接口名的后面：

 public interface List<T> extends Collection<T> {

 ... 

 } 

 

简单的说，类型变量扮演的角色就如同一个参数，它提供给编译器用来类型检查的信息。

Java类库里的很多类，例如整个Collection框架都做了泛型化的修改。例如，我们在上面的第一段代码里用到的List接口就是一个泛型类。在那段代码里，box是一个List<Apple>对象，它是一个带有一个Apple类型变量的List接口的类实现的实例。编译器使用这个类型变量参数在get方法被调用、返回一个Apple对象时自动对其进行类型转换。

实际上，这新出现的泛型标记，或者说这个List接口里的get方法是这样的：

T get(int index);

 

get方法实际返回的是一个类型为T的对象，T是在List<T>声明中的类型变量。

泛型方法和构造器(Constructor)

非常的相似，如果方法和构造器上声明了一个或多个类型变量，它们也可以泛型化。

public static <t> T getFirst(List<T> list)

 

这个方法将会接受一个List<T>类型的参数，返回一个T类型的对象。

例子

你既可以使用Java类库里提供的泛型类，也可以使用自己的泛型类。

类型安全的写入数据…

下面的这段代码是个例子，我们创建了一个List<String>实例，然后装入一些数据：

List<String> str = new ArrayList<String>(); 
str.add("Hello "); 
str.add("World."); 

 

如果我们试图在List<String>装入另外一种对象，编译器就会提示错误：

str.add(1); // 不能编译

 

类型安全的读取数据…

当我们在使用List<String>对象时，它总能保证我们得到的是一个String对象：

String myString = str.get(0);

 

遍历

类库中的很多类，诸如Iterator<T>，功能都有所增强，被泛型化。List<T>接口里的iterator()方法现在返回的是Iterator<T>，由它的T next()方法返回的对象不需要再进行类型转换，你直接得到正确的类型。

for (Iterator<String> iter = str.iterator(); iter.hasNext();) { 

   String s = iter.next(); 
   System.out.print(s); 

} 

 

使用foreach

“for each”语法同样受益于泛型。前面的代码可以写出这样：

for (String s: str) { 

    System.out.print(s); 

} 

 

这样既容易阅读也容易维护。

自动封装(Autoboxing)和自动拆封(Autounboxing)

在使用Java泛型时，autoboxing/autounboxing这两个特征会被自动的用到，就像下面的这段代码：

List<Integer> ints = new ArrayList<Integer>(); 
ints.add(0); 
ints.add(1);

int sum = 0; 
for (int i : ints) {
	sum += i; 
} 

 

     

然而，你要明白的一点是，封装和解封会带来性能上的损失，所有，通用要谨慎的使用。

子类型

在Java中，跟其它具有面向对象类型的语言一样，类型的层级可以被设计成这样：

在Java中，类型T的子类型既可以是类型T的一个扩展，也可以是类型T的一个直接或非直接实现(如果T是一个接口的话)。因为“成为某类型的子类型”是一个具有传递性质的关系，如果类型A是B的一个子类型，B是C的子类型，那么A也是C的子类型。在上面的图中：

• FujiApple(富士苹果)是Apple的子类型
• Apple是Fruit(水果)的子类型
• FujiApple(富士苹果)是Fruit(水果)的子类型

所有Java类型都是Object类型的子类型。

B类型的任何一个子类型A都可以被赋给一个类型B的声明：

Apple a = ...; 

Fruit f = a; 

 

泛型类型的子类型

如果一个Apple对象的实例可以被赋给一个Fruit对象的声明，就像上面看到的，那么，List<Apple> 和  List<Fruit>之间又是个什么关系呢？更通用些，如果类型A是类型B的子类型，那C<A> 和 C<B>之间是什么关系？

答案会出乎你的意料：没有任何关系。用更通俗的话，泛型类型跟其是否子类型没有任何关系。

这意味着下面的这段代码是无效的：

List<Apple> apples = ...; 

List<Fruit> fruits = apples; 

 

下面的同样也不允许：

List<Apple> apples; 

List<Fruit> fruits = ...; 

apples = fruits; 

 

为什么？一个苹果是一个水果，为什么一箱苹果不能是一箱水果？

在某些事情上，这种说法可以成立，但在类型(类)封装的状态和操作上不成立。如果把一箱苹果当成一箱水果会发生什么情况？

List<Apple> apples = ...; 

List<Fruit> fruits = apples; 

fruits.add(new Strawberry()); 

 

如果可以这样的话，我们就可以在list里装入各种不同的水果子类型，这是绝对不允许的。

另外一种方式会让你有更直观的理解：一箱水果不是一箱苹果，因为它有可能是一箱另外一种水果，比如草莓(子类型)。

这是一个需要注意的问题吗？

应该不是个大问题。而程序员对此感到意外的最大原因是数组和泛型类型上用法的不一致。对于泛型类型，它们和类型的子类型之间是没什么关系的。而对于数组，它们和子类型是相关的：如果类型A是类型B的子类型，那么A[]是B[]的子类型：

Apple[] apples = ...; 

Fruit[] fruits = apples; 

 

可是稍等一下！如果我们把前面的那个议论中暴露出的问题放在这里，我们仍然能够在一个apple类型的数组中加入strawberrie(草莓)对象：

 

Apple[] apples = new Apple[1]; 

Fruit[] fruits = apples; 

fruits[0] = new Strawberry(); 

 

这样写真的可以编译，但是在运行时抛出ArrayStoreException异常。因为数组的这特点，在存储数据的操作上，Java运行时需要检查类型的兼容性。这种检查，很显然，会带来一定的性能问题，你需要明白这一点。

重申一下，泛型使用起来更安全，能“纠正”Java数组中这种类型上的缺陷。

现在估计你会感到很奇怪，为什么在数组上会有这种类型和子类型的关系，我来给你一个《Java Generics and Collections》这本书上给出的答案：如果它们不相关，你就没有办法把一个未知类型的对象数组传入一个方法里(不经过每次都封装成Object[])，就像下面的：

void sort(Object[] o);

 

泛型出现后，数组的这个个性已经不再有使用上的必要了(下面一部分我们会谈到这个)，实际上是应该避免使用。

通配符

在本文的前面的部分里已经说过了泛型类型的子类型的不相关性。但有些时候，我们希望能够像使用普通类型那样使用泛型类型：

• 向上造型一个泛型对象的引用
• 向下造型一个泛型对象的引用

向上造型一个泛型对象的引用

例如，假设我们有很多箱子，每个箱子里都装有不同的水果，我们需要找到一种方法能够通用的处理任何一箱水果。更通俗的说法，A是B的子类型，我们需要找到一种方法能够将C<A>类型的实例赋给一个C<B>类型的声明。

为了完成这种操作，我们需要使用带有通配符的扩展声明，就像下面的例子里那样：

List<Apple> apples = new ArrayList<Apple>(); 

List<? extends Fruit> fruits = apples; 

 

“? extends”是泛型类型的子类型相关性成为现实：Apple是Fruit的子类型，List<Apple> 是 List<? extends Fruit> 的子类型。

向下造型一个泛型对象的引用

现在我来介绍另外一种通配符：? super。如果类型B是类型A的超类型(父类型)，那么C<B> 是 C<? super A> 的子类型：

List<Fruit> fruits = new ArrayList<Fruit>(); 

List<? super Apple> = fruits; 

 

为什么使用通配符标记能行得通？

原理现在已经很明白：我们如何利用这种新的语法结构？

? extends

让我们重新看看这第二部分使用的一个例子，其中谈到了Java数组的子类型相关性：

Apple[] apples = new Apple[1]; 

Fruit[] fruits = apples; 

fruits[0] = new Strawberry();  

 

就像我们看到的，当你往一个声明为Fruit数组的Apple对象数组里加入Strawberry对象后，代码可以编译，但在运行时抛出异常。

现在我们可以使用通配符把相关的代码转换成泛型：因为Apple是Fruit的一个子类，我们使用? extends 通配符，这样就能将一个List<Apple>对象的定义赋到一个List<? extends Fruit>的声明上：

List<Apple> apples = new ArrayList<Apple>(); 

List<? extends Fruit> fruits = apples; 

fruits.add(new Strawberry()); 

 

这次，代码就编译不过去了！Java编译器会阻止你往一个Fruit list里加入strawberry。在编译时我们就能检测到错误，在运行时就不需要进行检查来确保往列表里加入不兼容的类型了。即使你往list里加入Fruit对象也不行：

fruits.add(new Fruit()); 

 

你没有办法做到这些。事实上你不能够往一个使用了? extends的数据结构里写入任何的值。

原因非常的简单，你可以这样想：这个? extends T 通配符告诉编译器我们在处理一个类型T的子类型，但我们不知道这个子类型究竟是什么。因为没法确定，为了保证类型安全，我们就不允许往里面加入任何这种类型的数据。另一方面，因为我们知道，不论它是什么类型，它总是类型T的子类型，当我们在读取数据时，能确保得到的数据是一个T类型的实例：

Fruit get = fruits.get(0);

 

? super

使用 ? super 通配符一般是什么情况？让我们先看看这个：

List<Fruit> fruits = new ArrayList<Fruit>(); 

List<? super Apple> = fruits; 

 

我们看到fruits指向的是一个装有Apple的某种超类(supertype)的List。同样的，我们不知道究竟是什么超类，但我们知道Apple和任何Apple的子类都跟它的类型兼容。既然这个未知的类型即是Apple，也是GreenApple的超类，我们就可以写入：

fruits.add(new Apple()); 

fruits.add(new GreenApple()); 

 

如果我们想往里面加入Apple的超类，编译器就会警告你：

fruits.add(new Fruit()); 

fruits.add(new Object()); 

 

因为我们不知道它是怎样的超类，所有这样的实例就不允许加入。

从这种形式的类型里获取数据又是怎么样的呢？结果表明，你只能取出Object实例：因为我们不知道超类究竟是什么，编译器唯一能保证的只是它是个Object，因为Object是任何Java类型的超类。

存取原则和PECS法则

总结 ? extends 和 the ? super 通配符的特征，我们可以得出以下结论：

• 如果你想从一个数据类型里获取数据，使用 ? extends 通配符
• 如果你想把对象写入一个数据结构里，使用 ? super 通配符
• 如果你既想存，又想取，那就别用通配符。

这就是Maurice Naftalin在他的《Java Generics and Collections》这本书中所说的存取原则，以及Joshua Bloch在他的《Effective Java》这本书中所说的PECS法则。

Bloch提醒说，这PECS是指”Producer Extends, Consumer Super”，这个更容易记忆和运用。

 

--------------------------------------通配符基本介绍------------------------------------------------

自从泛型被添加到 JDK 5 语言以来，它一直都是一个颇具争议的话题。一部分人认为泛型简化了编程，扩展了类型系统从而使编译器能够检验类型安全；另外一些人认为泛型添加了很多不必要的复杂性。对于泛型我们都经历过一些痛苦的回忆，但毫无疑问通配符是最棘手的部分。

泛型是一种表示类或方法行为对于未知类型的类型约束的方法，比如 “不管这个方法的参数 x 和 y 是哪种类型，它们必须是相同的类型”，“必须为这些方法提供同一类型的参数” 或者 “foo() 的返回值和 bar() 的参数是同一类型的”。

通配符 — 使用一个奇怪的问号表示类型参数 — 是一种表示未知类型的类型约束的方法。通配符并不包含在最初的泛型设计中（起源于 Generic Java（GJ）项目），从形成 JSR 14 到发布其最终版本之间的五年多时间内完成设计过程并被添加到了泛型中。

通配符在类型系统中具有重要的意义，它们为一个泛型类所指定的类型集合提供了一个有用的类型范围。对泛型类 ArrayList 而言，对于任意（引用）类型 T，ArrayList<?> 类型是 ArrayList<T> 的超类型（类似原始类型 ArrayList 和根类型 Object，但是这些超类型在执行类型推断方面不是很有用）。

通配符类型 List<?> 与原始类型 List 和具体类型 List<Object> 都不相同。如果说变量 x 具有 List<?> 类型，这表示存在一些 T 类型，其中 x 是 List<T>类型，x 具有相同的结构，尽管我们不知道其元素的具体类型。这并不表示它可以具有任意内容，而是指我们并不了解内容的类型限制是什么 — 但我们知道存在 某种限制。另一方面，原始类型 List 是异构的，我们不能对其元素有任何类型限制，具体类型 List<Object> 表示我们明确地知道它能包含任何对象（当然，泛型的类型系统没有 “列表内容” 的概念，但可以从 List 之类的集合类型轻松地理解泛型）。

 

通配符在类型系统中的作用部分来自其不会发生协变（covariant）这一特性。数组是协变的，因为 Integer 是 Number 的子类型，数组类型 Integer[] 是 Number[] 的子类型，因此在任何需要 Number[] 值的地方都可以提供一个 Integer[] 值。另一方面，泛型不是协变的， List<Integer> 不是 List<Number> 的子类型，试图在要求 List<Number> 的位置提供 List<Integer> 是一个类型错误。这不算很严重的问题 — 也不是所有人都认为的错误 — 但泛型和数组的不同行为的确引起了许多混乱。

我已使用了一个通配符 — 接下来呢？

清单 1 展示了一个简单的容器（container）类型 Box，它支持 put 和 get 操作。 Box 由类型参数 T 参数化，该参数表示 Box 内容的类型， Box<String> 只能包含 String 类型的元素。

清单 1. 简单的泛型 Box 类型

                
public interface Box<T> {
    public T get();
    public void put(T element);
}

通配符的一个好处是允许编写可以操作泛型类型变量的代码，并且不需要了解其具体类型。例如，假设有一个 Box<?> 类型的变量，比如清单 2 unbox() 方法中的 box 参数。unbox() 如何处理已传递的 box？

清单 2. 带有通配符参数的 Unbox 方法

                
public void unbox(Box<?> box) {
    System.out.println(box.get());
}

事实证明 Unbox 方法能做许多工作：它能调用 get() 方法，并且能调用任何从 Object 继承而来的方法（比如 hashCode()）。它惟一不能做的事是调用 put() 方法，这是因为在不知道该 Box 实例的类型参数 T 的情况下它不能检验这个操作的安全性。由于 box 是一个 Box<?> 而不是一个原始的 Box，编译器知道存在一些 T 充当 box 的类型参数，但由于不知道 T 具体是什么，您不能调用 put() 因为不能检验这么做不会违反 Box 的类型安全限制（实际上，您可以在一个特殊的情况下调用 put()：当您传递 null 字母时。我们可能不知道 T 类型代表什么，但我们知道 null 字母对任何引用类型而言是一个空值）。

关于 box.get() 的返回类型，unbox() 了解哪些内容呢？它知道 box.get() 是某些未知 T 的 T，因此它可以推断出 get() 的返回类型是 T 的擦除（erasure），对于一个无上限的通配符就是 Object。因此清单 2 中的表达式 box.get() 具有 Object 类型。

通配符捕获

清单 3 展示了一些似乎应该 可以工作的代码，但实际上不能。它包含一个泛型 Box、提取它的值并试图将值放回同一个 Box。

清单 3. 一旦将值从 box 中取出，则不能将其放回

                
public void rebox(Box<?> box) {
    box.put(box.get());
}

Rebox.java:8: put(capture#337 of ?) in Box<capture#337 of ?> cannot be applied
   to (java.lang.Object)
    box.put(box.get());
       ^
1 error

这个代码看起来应该可以工作，因为取出值的类型符合放回值的类型，然而，编译器生成（令人困惑的）关于 “capture#337 of ?” 与 Object 不兼容的错误消息。

“capture#337 of ?” 表示什么？当编译器遇到一个在其类型中带有通配符的变量，比如 rebox() 的 box 参数，它认识到必然有一些 T ，对这些 T 而言 box 是 Box<T>。它不知道 T 代表什么类型，但它可以为该类型创建一个占位符来指代 T 的类型。占位符被称为这个特殊通配符的捕获（capture）。这种情况下，编译器将名称 “capture#337 of ?” 以 box 类型分配给通配符。每个变量声明中每出现一个通配符都将获得一个不同的捕获，因此在泛型声明 foo(Pair<?,?> x, Pair<?,?> y) 中，编译器将给每四个通配符的捕获分配一个不同的名称，因为任意未知的类型参数之间没有关系。

错误消息告诉我们不能调用 put()，因为它不能检验 put() 的实参类型与其形参类型是否兼容 — 因为形参的类型是未知的。在这种情况下，由于 ? 实际表示 “？extends Object” ，编译器已经推断出 box.get() 的类型是 Object，而不是 “capture#337 of ?”。它不能静态地检验对由占位符 “capture#337 of ?” 所识别的类型而言 Object 是否是一个可接受的值。

捕获助手

虽然编译器似乎丢弃了一些有用的信息，我们可以使用一个技巧来使编译器重构这些信息，即对未知的通配符类型命名。清单 4 展示了 rebox() 的实现和一个实现这种技巧的泛型助手方法（helper）：

清单 4. “捕获助手” 方法

                
public void rebox(Box<?> box) {
    reboxHelper(box);
}

private<V> void reboxHelper(Box<V> box) {
    box.put(box.get());
}

助手方法 reboxHelper() 是一个泛型方法，泛型方法引入了额外的类型参数（位于返回类型之前的尖括号中），这些参数用于表示参数和/或方法的返回值之间的类型约束。然而就 reboxHelper() 来说，泛型方法并不使用类型参数指定类型约束，它允许编译器（通过类型接口）对 box 类型的类型参数命名。

捕获助手技巧允许我们在处理通配符时绕开编译器的限制。当 rebox() 调用 reboxHelper() 时，它知道这么做是安全的，因为它自身的 box 参数对一些未知的 T 而言一定是 Box<T>。因为类型参数 V 被引入到方法签名中并且没有绑定到其他任何类型参数，它也可以表示任何未知类型，因此，某些未知 T 的 Box<T> 也可能是某些未知 V 的 Box<V>（这和 lambda 积分中的 α 减法原则相似，允许重命名边界变量）。现在 reboxHelper() 中的表达式 box.get() 不再具有 Object 类型，它具有 V 类型 — 并允许将 V 传递给 Box<V>.put()。

我们本来可以将 rebox() 声明为一个泛型方法，类似 reboxHelper()，但这被认为是一种糟糕的 API 设计样式。此处的主要设计原则是 “如果以后绝不会按名称引用，则不要进行命名”。就泛型方法来说，如果一个类型参数在方法签名中只出现一次，它很有可能是一个通配符而不是一个命名的类型参数。一般来说，带有通配符的 API 比带有泛型方法的 API 更简单，在更复杂的方法声明中类型名称的增多会降低声明的可读性。因为在需要时始终可以通过专有的捕获助手恢复名称，这个方法让您能够保持 API 整洁，同时不会删除有用的信息。

类型推断

捕获助手技巧涉及多个因素：类型推断和捕获转换。Java 编译器在很多情况下都不能执行类型推断，但是可以为泛型方法推断类型参数（其他语言更加依赖类型推断，将来我们可以看到 Java 语言中会添加更多的类型推断特性）。如果愿意，您可以指定类型参数的值，但只有当您能够命名该类型时才可以这样做 — 并且不能够表示捕获类型。因此要使用这种技巧，要求编译器能够为您推断类型。捕获转换允许编译器为已捕获的通配符产生一个占位符类型名，以便对它进行类型推断。

当解析一个泛型方法的调用时，编译器将设法推断类型参数它能达到的最具体类型。 例如，对于下面这个泛型方法：

 

public static<T> T identity(T arg) { return arg }; 

和它的调用：

 

Integer i = 3;
System.out.println(identity(i));

编译器能够推断 T 是 Integer、Number、 Serializable 或 Object，但它选择 Integer 作为满足约束的最具体类型。

当构造泛型实例时，可以使用类型推断减少冗余。例如，使用 Box 类创建 Box<String> 要求您指定两次类型参数 String：

 

Box<String> box = new BoxImpl<String>();

即使可以使用 IDE 执行一些工作，也不要违背 DRY（Don't Repeat Yourself）原则。然而，如果实现类 BoxImpl 提供一个类似清单 5 的泛型工厂方法（这始终是个好主意），则可以减少客户机代码的冗余：

清单 5. 一个泛型工厂方法，可以避免不必要地指定类型参数

                
public class BoxImpl<T> implements Box<T> {

    public static<V> Box<V> make() {
        return new BoxImpl<V>();
    }

    ...
}

如果使用 BoxImpl.make() 工厂实例化一个 Box，您只需要指定一次类型参数：

 

Box<String> myBox = BoxImpl.make();

泛型 make() 方法为一些类型 V 返回一个 Box<V>，返回值被用于需要 Box<String> 的上下文中。编译器确定 String 是 V 能接受的满足类型约束的最具体类型，因此此处将 V 推断为 String。您还可以手动地指定 V 的值：

 

Box<String> myBox = BoxImpl.<String>make();

除了减少一些键盘操作以外，此处演示的工厂方法技巧还提供了优于构造函数的其他优势：您能够为它们提高更具描述性的名称，它们能够返回命名返回类型的子类型，它们不需要为每次调用创建新的实例，从而能够共享不可变的实例（参见 参考资料 中的 Effective Java, Item #1，了解有关静态工厂的更多优点）。

结束语

通配符无疑非常复杂：由 Java 编译器产生的一些令人困惑的错误消息都与通配符有关，Java 语言规范中最复杂的部分也与通配符有关。然而如果使用适当，通配符可以提供强大的功能。此处列举的两个技巧 — 捕获助手技巧和泛型工厂技巧 — 都利用了泛型方法和类型推断，如果使用恰当，它们能显著降低复杂性。