csdn1428208016

泛型

简单泛型
泛型接口
泛型方法
匿名内部类
擦除的神秘之处
擦除的补偿

泛型数组

边界
通配符

逆变
无边界通配符
捕获转换

问题
自限定的类型

一般的类和方法，只能使用具体的类型：要么是基本类型，要么是自定义的类。如果要编写可以应用于多种类型的代码，这种刻板的限制对代码的東缚就会很大。

有时候拘泥于单继承体系，也会使程序受限太多。如果方法的参数是一个接口，而不是一个类，这种限制就放松了许多。可是有的时候即便使用了接口，对程序的约束也还是太强了。因为一旦指明了接口，它就要求你的代码必须使用特定的接口。而我们希望达到的目的是编写更通用的代码，要使代码能够应用与，“某种不具体的类型”，而不是一个具体的接口或类。

这就是Java SE5的重大变化之一：泛型的概念。泛型实现了参数化类型的概念，使代码可以应用于多种类型。“泛型”这个术语的意思是：“适用于许多许多的类型”。泛型在编程语言中出现时，其最初的目的是希望类或方法能够具备最广泛的表达能力。如何做到这一点呢，正是通过解耦类或方法与所使用的类型之间的约束。实际上，你可能会质疑，Java中的术语“泛型”是否适合用来描述这一功能。

简单泛型

有许多原因促成了泛型的出现，而最引人注目的一个原因，就是为了创造容器类。有些情况下,我们确实希望容器能够同时持有多种类型的对象。但是，通常而言我们只会使用容器来存储一种类型的对象。泛型的主要目的之一就是用来指定容器要持有什么类型的，因此与其使用Object，我们更喜欢暂时不指定类型，而是稍后再決定具体使用什么类型。要达到这个目的，需要使用类型参数，用尖括号括住，放在类名后面。然后在使用这个类的时候，再用实际的类型替换此类型参数。在下面的例子中，T就是类型参数：

class Tt{}
public class Holder<T> {
	private T a;
	public Holder(T a){this.a = a;}
	public T get(){return a;}
	public static void main(String[] args) {
		Tt t = new Tt();
		Holder<Tt> h = new Holder<Tt>(t);
		h.get();
	}
}

现在，当你创建Holder对象时，必须指明想持有什么类型的对象，将其置于尖括号内。然后，你就只能在Holder中存入该类型（或其子类，因为多态与泛型不冲突）的对象了。并且，在你从Holder中取出它持有的对象时，自动地就是正确的类型。

这就是Java泛型的核心概念：告诉编译器想使用什么类型，然后编译器帮你处理一切细节。

一个元组类库

仅一次方法调用就能返回多个对象，你应该经常需要这样的功能吧。可是return语句只允许返回单个对象，因此解决办法就是创建一个对象，用它来持有想要返回的多个对象。现在我们有了泛型，就能够一次性地解决该问题，以后再也不用在这个问题上浪费时间了。同时,我们在编译器就能确保类型安全。

这个概念称为元组（tuple），它是将一组对象直接打包存储于其中的一个单一对象。这个容器对象允许读取其中元素，但是不允许向其中存放新的对象。（这个概念也称为数据传道对象，或信使。）

通常，元组可以具有任意长度。我们也可以利用继承机制实现长度更长的元组。从下面的例子中可以看到，增加类型参数是件很简单的事情：

class TwoTuple<A,B>{
	public A a;
	public B b;
	public TwoTuple(A a,B b) {
		this.a = a;
		this.b = b;
	}
}
public class ThreeTuple<A,B,C> extends TwoTuple<A,B> {
	public C c;
	public ThreeTuple(A a,B b,C c) {
		super(a,b);
		this.c = c;
	}
}

泛型接口

泛型也可以应用于接口。例如生成器（generator），这是一种专门负责创建对象的类。实际上这是工厂方法设计模式的一种应用。不过，当使用生成器创建新的对象时，它不需要任何参数数，而工厂方法一般需要参数。也就是说生成器无需额外的信息就知道如何创建新对象。一般而言，一个生成器只定义一个方法，该方法用以产生新的对象。

public interface Generator<T>{
	T next();
}

方法next()的返回类型是参数化的T。正如你所见到的，接口使用泛型与类使用泛型没什么区别。

泛型方法

到目前为止，我们看到的泛型都是应用于整个类上。但同样可以在类中包含参数化方法，而这个方法所在的类可以是泛型类，也可以不是泛型类。也就是说，是否拥有泛型方法与其所在的类是否是泛型没有关系。

泛型方法使得该方法能够独立于类而产生变化。以下是一个基本的指导原则：无论何时，只要你能做到，你就应该尽量使用泛型方法。也就是说，如果使用泛型方法可以取代将整个类泛型化，那么就应该只使用泛型方法，因为它可以使事情更清楚明白。另外，对于一个static的方法而言，无法访问泛型类的类型参数。所以，如果static方法需要使用泛型能力，就必须使其成为泛型方法。

要定义泛型方法只需将泛型参数列表置于返回值之前，就像下面这样：

public class Test {
	public <T> void f(T x){
		System.out.println(x.getClass().getName());
	}
}

注意，当使用泛型类时，必须在创建对象的时候指定类型参数的值，而使用泛型方法的时候，通常不必指明参数类型，因为编译器会为我们找出具体的类型。这称为类型参数推断（type argument inference）。因此，我们可以像调用普通方法一样调用f()，而且就好像是f()被无限次地
重载过。如果调用f()时传入基本类型，自动打包机制就会介入其中，将基本类型的使包装为对应的对象。事实上，泛型方法与自动打包避免了许多以前我们不得不自己编写出来的代码。

杠杆利用类型参数推断

类型推断只对赋值操作有效，其他时候并不起作用。如果你将一个泛型方法调用的结果作为参数传递给另一个方法，这时编译器并不会执行类型推断。在这种情况下，编译器认为：调用泛型方法后其返回値被赋给一个Objeet类型的变量。

显式的类型说明

在泛型方法中，可以显式地指明类型，不过这种语法很少使用。要显式地指明类型，必须在点操作符与方法名之间插入尖括号，然后把类型置于尖括号内。如果是在定义该方法的类的内部，必须在点操作符之前使用this关键字，如果是使用static的方法，必须在点操作符之前加上类名。例：

public class Test {
	public <T> void f(T x){
		System.out.println(x.getClass().getName());
	}
	static <T> Test g(){
		return new Test();
	}
	static  void h(Test t){
	}
	public static void main(String[] args) {
		h(Test.<Test>g());
	}
}

可变参数类型与泛型
泛型方法与可变参数列表能够很好地共存。

public class Test {
	public static <T> List<T> makeList(T... ts){
		List<T> list = new LinkedList<T>();
		for(T t:ts){
			list.add(t);
		}
		return list;
	}
	public static void main(String[] args) {
		List<String> list = makeList("1","2","3");
		for(String str :list){
			System.out.print(str+",");
		}
	}
	//输出：1,2,3,
}

匿名内部类

泛型还可以应用于内部类以及匿名内部类，例：

public interface Generator<T>{
	T next();
}
public class Test {
	class Customer{}
	public static Generator<Customer> generator(){
		return new Generator<Test.Customer>() {
			@Override
			public Customer next() {
				return null;
			}
		};
	}
}

擦除的神秘之处

当你开始更深入地钻研泛型时，会发现有大量的东西初看起来是没有意义的。例如，尽管可以声明ArrayList.class，但是不能声明ArrayList.class。请考虑下面的情况：

public class Test {
	public static void main(String[] args) {
		Class c1 = new ArrayList<Integer>().getClass();
		Class c2 = new ArrayList<String>().getClass();
		System.out.println(c1 == c2);
	}
	//输出：
	//true
}

ArrayList和ArrayList很容易被认为是不同的类型。不同的类型在行为方面肯定不同，例如如果尝试着将一个Integer放入ArrayList所得到的行为（将失败），与把一个Integer放入ArrayList（将成功）所得到的行为完全不同。但是上面的程序会认为它们是相同的类型。

根据JDK文档的描述，Class.getTepeParameters()将“返回一个TypeVariable对象数组，表示有泛型声明所声明的类型参数……”这好像是在暗示你可能发现参数类型的信息，但是，正如你从输出中所看到的，你能够发现的只是用作参数占位符的标识符，这并非有用的信息。因此残酷的现实是：

在泛型代码内部，无法获得何有关泛型参数类型的信息。

因此，你可以知道诸如类型参数标识符和泛型类型边界这类的信息——你却无法知道用来创建某个特定实例的实际的类型参数。在使用Java泛型工作时它是必须处理的最基本的问题。

Java泛型是使用擦除来实现的，这意味着当你在使用泛型时，任何具体的类型信息都被擦除了，你唯一知道的就是你在使用一个对象。因此List和List在运行时事实上是相同的类型。这两种形式都被擦除成它们的“原生”类型，即List。请看下面的示例：

class HasF{
	public void f(){
		System.out.println("hasF.f()");
	}
}
class Maninpulator<T>{
	private T obj;
	public Maninpulator(T t){
		this.obj = t;
	}
	public void manipulate(){
		obj.f();//Error!
	}
}

由于有了擦除，Java编译器无法将manipulate()必须能够在obj上调用f()这一需求映射到HasF拥有f()这一事实上。为了调用f()，我们必须协助泛型类，给定泛型类的边界，以此告知编译器只能接受遵循这个边界的类型。这里重用了extends关键字。由于有了边界，下面的代码就可以编译了：

class Maninpulator2<T extends HasF>{
	private T obj;
	public Maninpulator2(T t){
		this.obj = t;
	}
	public void manipulate(){
		obj.f();
	}
}

边界声明T必须具有类型HasF或者从HasF导出的类型。如果情况确实如此，那么就可以安全地在obj上调用f()了。

我们说泛型类型参数将擦除到它的第一个边界（它可能会有多个边界），我们还提到了类型参数的擦除。编译器实际上会把类型参数替换为它的擦除，就像上面的示例一样。T擦除到了HasF，就好像在类的声明中用HasF替换了T一样。

你可能已经正确地观察到,在上例Maninpulator2类中，泛型没有贡献任何好处。只需很容易地自己去执行擦除，就可以创建出没有泛型的类。这提出了很重要的一点：只有当你希望使用的类型参数比某个具体类型（以及它的所有子类型）更加“泛化”时——也就是说，当你希望代码能够跨多个类工作时，使用泛型才有所帮助。因此，类型参数和它们在有用的泛型代码中的应用，通常比简单的类替换要更复杂。但是，不能因此而认为形式的任何东西而都是有缺陷的。例如，如果某个类有一个返回T的方法，那么泛型就有所帮助，因为它们之后将返回确切的类型：

class Maninpulator2<T extends HasF>{
	private T obj;
	public Maninpulator2(T t){
		this.obj = t;
	}
	public T get(){
		return obj;
	}
}

必须査看所有的代码，并确定它是否“足够复杂”到必须使用泛型的程度。

迁移兼容性

为了减少潜在的关于擦除的混淆，你必须清楚地认识到这不是一个语言特性。它是Java的泛型实现中的一种折中，因为泛型不是Java语言出现时就有的组成部分，所以这种折中是必需的。这种折中会使你痛苦，因此你需要习惯它并了解为什么它会是这样。

如果泛型在Java 1.0中就已经是其一部分了，那么这个特性将不会使用擦除来实现——它将使用具体化，使类型参数保持为第一类实体，因此你就能够在类型参数上执行基于类型的语言操作和反射操作。擦除减少了泛型的泛化性，泛型在Java中仍旧是有用的，只是不如它们本来设想的那么有用，而原因就是擦除。

在基于擦除的实现中，泛型类型被当作第二类类型处理，即不能在某些重要的上下文环境中使用的类型。泛型类型只有在静态类型检査期间才出现，在此之后，程序中的所有泛型类型都将被擦除，替换为它们的非泛型上界。例如，诸如List这样的类型注解将被擦除为List，而普通的类型变量在未指定边界的情况下将被擦除为Object。

擦除的核心动机是它使得泛化的客户端可以用非泛化的类库来使用，反之亦然，这经常被称为“迁移兼容性”。在理想情况下，当所有事物都可以同时被泛化时，我们就可以专注于此。在现实中，即使程序员只编写泛型代码，他们也必须处理在Java SE5之前编写的非泛型类库。那些类库的作者可能从没有想过要泛化它们的代码，或者可能刚刚开始接触泛型。

因此Java泛型不仅必须支持向后兼容性，即现有的代码和类文件仍旧合法，并且继续保持其之前的含义；而且还要支持迁移兼容性，使得类库按照它们自己的步调变为泛型的，并且当某个类库变为泛型时，不会破坏依赖于它的代码和应用程序。在决定这就是目标之后，Java设计者们和从事此同题相关工作的各个团队决策认为擦除是唯一可行的解决方案。通过允许非泛型代码与泛型代码共存，擦除使得这种向着泛型的迁移成为可能。

例如，假设某个应用程序具有两个类库X和Y，并且Y还要使用类库Z。随着Java SE5的出现，这个应用程序和这些类库的创建者最终可能希望迁移到泛型上。但是，当进行这种迁移时，他们有着不同动机和限制。为了实现迁移兼容性，每个类库和应用程序都必须与其他所有的部分是否使用了泛型无关。这样，它们必须不具备探测其他类库是否使用了泛型的能力。因此，某个特定的类库使用了泛型这样的证据必须被“擦除”。

如果没有某种类型的迁移途径，所有已经构建了很长时间的类库就需要与希望迁移到Java 泛型上的开发者们说再见了。但是，类库是编程语言无可争议的一部分，它们对生产效率会产生最重要的影响，因此这不是一种可以接受的代价。擦除是否是最佳的或者唯一的迁移途径，还需要时间来证明。

擦除的问题

因此，擦除主要的正当理由是从非泛化代码到泛化代码的转变过程，以及在不破坏现有类库的情况下，将泛型融入Java语言。擦除使得现有的非泛型客户端代码能够在不改变的情况下继续使用，直至客户端准备好用泛型重写这些代码。这是一个崇高的动机，因为它不会突然间破坏所有现有的代码。

擦除的代价是显著的。泛型不能用于显式地引用运行时类型的操作之中，例如转型、instanceof操作和new表达式。因为所有关于参数的类型信息都丢失了，无论何时，当你在编写泛型代码时，必须时刻提醒自己，你只是看起来好像拥有有关参数的类型信息而已。因此，如果你编写了下面这样的代码段：

class Foo<T>{
	T var;
}

那么，看起来当你在创建Foo的实例时：

Foo<Cat> f = new Foo<Cat>();

class Foo中的代码应该知道现在工作于Cat之上，而泛型语法也在强烈暗示：在整个类中的各个地方，类型T都在被替换。但是事实并非如此，无论何时，当你在编写这个类的代码时，必须提醒自己：“不，它只是一个Object。”

边界处的动作

正是因为有了擦除，我发现泛型最令人困惑的方面源自这样一个事实，即可以表示没有任何意义的事物。

因为擦除在方法体中移除了类型信息，所以在运行时的问题就是边界：即对象进入和离开方法的地点。这些正是编译器在编译期执行类型检査并插入转型代码的地点。所以在泛型中的所有动作都发生在边界处——对传递进来的值进行额外的编译期检査，并插入对传递出去的值的转型。这有助于澄清对擦除的混淆，记住，“边界就是发生动作的地方。”

擦除的补偿

正如我们看到的，擦除丢失了在泛型代码中执行某些操作的能力。任何在运行时需要知道确切类型信息的操作都将无法工作：

public class Test<T> {
	private final int SIZE = 100;
	public static void f(Object arg){
		if (arg instanceof T) {}//Error;
		T v = new T();//Error
	}
}

偶尔可以绕过这些问题来编程，但是有时必须通过引入类型标签来对擦除进行补偿。这意味着你需要显式地传递你的类型的Class对象，以便你可以在类型表达式中使用它。

在前面示例中对使用instanceof的尝试最终失败了，因为其类型信息已经被擦除了。如果引入类型标签，就可以转而使用动态的isInstance()：

class Building{}
public class Test<T> {
	Class<T> kind;
	public Test(Class<T> kind) {
		this.kind = kind;
	}
	public boolean f(Object obj){
		return this.kind.isInstance(obj);
	}
	public static void main(String[] args) {
		Building b = new Building();
		Test<Building> t = new Test<Building>(Building.class);
		System.out.println(t.f(b));
	}
	//输出：
	//true
}

编译器将确保类型标签可以匹配泛型参数。

创建类型实例

在上例中对创建一个new T()的尝试将无法实现，部分原因是因为擦除，而另一部分原因是因为编译器不能验证T具有默认（无参）构造器。解决方案就是使用显示的工厂，并将限制其类型。例：

interface Factory<T>{
	T create();
}
class Foo2<T>{
	private T x;
	public <F extends Factory<T>> Foo2(F f){
		x = f.create();
	}
}
class IntegerFactory implements Factory<Integer>{
	@Override
	public Integer create() {
		return new Integer(0);
	}
}
public class Test<T> {
	public static void main(String[] args) {
		new Foo2<Integer>(new IntegerFactory());
	}
}

另一种方式是模版方法设计模式。在下面的示例中，get()是模版方法，而create()是在子类中定义的，用来产生子类类型的对象（注：原文并没有发现get()方法，我这里没搞明白…）：

abstract class GeneriWithCerate<T>{
	final T element;
	GeneriWithCerate() { 
		element = create();
	}
	abstract T create();
}
class X {}
class Creator extends GeneriWithCerate<X>{
	@Override
	X create() {
		return new X();
	}
	void f(){
		System.out.println(element.getClass().getName());
	}
}

public class Test{
	public static void main(String[] args) {
		Creator c = new Creator();
		c.f();
	}
	//输出：
	//X
}

泛型数组

有时，你希望创建泛型类型的数组，有趣的是，可以按照编译器喜欢的方式来定义一个引用，例如：

class Generic<T>{}
public class Test{
	static Generic<Integer>[] gia;
}

编译器将接受这个程序，而不会产生任何警告。但是永远都不能创建这个确切类型的数组（包括类型参数），因此这有一点令人困惑。既然所有数组无论它们持有的类型如何，都具有相同的结构（每个数组槽位的尺寸和数组的布局），那么看起来你应该能够创建一个Object数组，并将其转型为所希望的数组类型。事实上这可以编译，但是不能运行，它将产生ClassCaseException。

class Generic<T>{}
public class Test{
	static final int SIZE = 100;
	static Generic<Integer>[] gia;
	public static void main(String[] args) {
		//!gia = (Generic[])new Object[SIZE]; 运行后这句将会抛出异常
		gia = (Generic<Integer>[])new Generic[SIZE];
		System.out.println(gia.getClass().getName());
	}
}

问题在于数组将跟踪它们的实际类型，而这个类型是在数组被创建时确定的，因此即使gia已经被转型为Generic[]，但是这个信息只存在于编译期。在运行时，它仍旧是Object数组，而这将引发问题。成功创建泛型数组的唯一方式就是创建一个被擦除类型的新数组，然后对其转型。例：

public class Test<T>{
	private T[] array;
	public Test(int sz) {
		array = (T[]) new Object[sz];
	}
	private T[] rep(){return array;}
	public static void main(String[] args) {
		Test<Integer> a = new Test<Integer>(10);
		//Integer[] is = a.rep(); Error
	}
}

与前面相同，我们并不能声明T[] array= new T[sz]，因此我们创建了一个对象数组，然后将其转型。

rep()方法将返回T[]，它在main()中将用于gai，因此应该是Integer[]，但是如果调用它，并尝试着将结果作为Integer[]引用来捕获，就会得到ClassCastException，这还是因为实际的运行时类型是Object[]。

因为有了擦除，数组的运行时类型就只能是Object[]。如果我们立即将其转型为T[]，那么在编译期该数组的实际类型就将丢失，而编译器可能会错过某些潜在的错误检査。正因为这样，最好是在集合内部使用0bject[]，然后当你使用数组元素时，添加一个对T的转型。例：

public class Test<T>{
	private Object[] array;
	public Test(int sz) {
		array = new Object[sz];
	}
	@SuppressWarnings("unchecked")
	public T[] rep(){return (T[]) array;}
	public void put(int i,T t){
		array[i] = t;
	}
	public T get(int i){
		return (T) array[i];
	}
	public static void main(String[] args) {
		Test<Integer> a = new Test<Integer>(10);
		for(int i = 0;i<10;i++){
			a.put(i, i);
		}
		for(int i = 0;i<10;i++){
			System.out.print(a.get(i));
		}
		Integer[] is = a.rep();
	}
}

初看起来，这好像没多大变化，只是转型挪了地方。但是，现在的内部表示是Object[]而不是T[]。当get()被调用时，它将对象转型为T，这实际上是正确的类型，因此这是安全的。然而，如果你调用一rep()，它还是尝试着将Object[]转型为T[]，这仍旧是不正确的，将在编译期产生警告，在运行时产生异常。因此，没有任何方式可以推翻底层的数组类型，它只能是Object[]。在内部将array当作Object[]而不是T[]处理的优势是：我们不太可能忘记这个数组的运行时类型，从而意外地引入缺陷（尽管大多数也可能是所有这类缺陷都可以在运行时快速地探测到）。

public class Test<T>{
	private T[] array;
	public Test(Class<T> type,int sz) {
		array = (T[]) Array.newInstance(type, sz);
	}
	@SuppressWarnings("unchecked")
	public T[] rep(){return (T[]) array;}
	public void put(int i,T t){
		array[i] = t;
	}
	public T get(int i){
		return (T) array[i];
	}
	public static void main(String[] args) {
		Test<Integer> a = new Test<Integer>(Integer.class,10);
		for(int i = 0;i<10;i++){
			a.put(i, i);
		}
		for(int i = 0;i<10;i++){
			System.out.print(a.get(i));
		}
		Integer[] is = a.rep();
	}
	//输出：
	//0123456789
}

类型标记Class被传递到构造器中，以便从擦除中恢复，使得我们可以创建需要的实际类型的数组，一旦我们获得了实际类型，就可以返回它，并获得想要的结果，就像在main()中看到的那样。该数组的运行时类型型是确切类型T[]。

边界

边界使得你可以在用于泛型的参数类型上设置限制条件。尽管这使得你可以强制规定泛型可以应用的类型，但是其潜在的一个更重要的效果是你可以按照自己的边界类型来调用方法。

因为擦除移除了类型信息，所以，可以用无界泛型参数调用的方法只是那些可以用Object调用的方法。但是，如果能够将这个参数限制为某个类型子集，那么你就可以用这些类型子集来调用方法。为了执行这种限制，Java泛型重用了extends关键字。对你来说有一点很重要，即要理解extends关键字在泛型边界上下文环境中和在普通情况下所具有的意义是完全不同的，下面的示例展示了边界的基本要素：

interface HasColor{Color color();}
class Colored<T extends HasColor>{
	T item;
	public Colored(T item) {
		this.item = item;
	}
	public T get(){
		return item;
	}
	public Color color(){
		return item.color();
	}
}
class X{public int x,y,z;}
class ColoredDimension<T extends X & HasColor>{
	T item;
	public ColoredDimension(T item) {
		this.item = item;
	}
	T getT(){
		return item;
	}
	int getX(){
		return item.x;
	}
}
public class Test{
	public static void main(String[] args) {
		X x = new X();
		ColoredDimension c = new ColoredDimension(x);
		System.out.println(c.getX());
		System.out.println(c.getT());
	}
	//输出：
	//0
	//thinkinjava.X@6c267f18
}

下面可以看到如何在继承的每个层次上添加边界限制

class HoldItem<T>{
	T item;
	public HoldItem(T item) {
		this.item = item;
	}
	T get(){return item;}
}
class Colored2<T extends HasColor> extends HoldItem<T>{
	public Colored2(T item) {
		super(item);
	}
	public Color color(){
		return item.color();
	}
}
class ColorDimension2<T extends X & HasColor> extends Colored2<T>{
	public ColorDimension2(T item) {
		super(item);
	}
	int getX(){
		return item.x;
	}
}
public class Test2 {
	public static void main(String[] args) {
		X x = new X();
		ColorDimension2 c = new ColorDimension2(x);
		c.get();
		c.getX();
	}
}

通配符

你应该看到过一些使用通配符的案例——在泛型参数表达式中的问号。

现在我们思考一个问题：有一个Apple数组，我们将它赋给一个Fruit数组引用，Apple继承于Fruit。这是有意义的，因为Apple也是一种Fruit，因此Apple数组应该也是一个Fruit数组。

但是，如果实际的数组类型是Apple[]，你应该只能在其中设置Apple或Apple的子类型，这在编译期和运行时都可以工作。但是请注意，编译器允许你将Fruit放置到这个数组中，这对于编译器来说是有意义的，因为它有一个Fruit[]引用——它有什么理由不允许将Fruit对象或者任何从Fruit继承出来的对象（例如Orange），放置到这个数组中呢？因此，在编译期，这是允许的。但是，运行时的数组机制知道它处理的是Apple[]，因此会在向数组中放置异构类型时抛出异常。

实际上，向上转型不合适用在这里。你真正做的是将一个数组赋值给另一个数组。数组的行为应该是它可以持有其他对象，这里只是因为我们能够向上转型而已，所以很明显数组对象可以保留有关它们包含的对象类型的规则。就好像数组对它们持有的对象是有意识的，因此在编译期检査和运行时检査之间，你不能滥用它们。

对数组的这种赋值并不是那么可怕，因为在运行时可以发现你已经插入了不正确的类型。但是泛型的主要目标之一是将这种错误检测移入到编译期。因此当我们试图使用泛型容器来代替数组时，会发生什么呢？我们可能会认为：“不能将一个Apple容器赋值给一个Fruit容器” 。别忘了，泛型不仅和容器相关正确的说法是：“不能把一个涉及Apple的泛型赋值给一个涉及Fruit的泛型”。如果就像在数组的情況中一样，编译器对代码的了解足够多，可以确定所涉及到的容器，那么它可能会留下一些余地。但是它不知道任何有关这方面的信息，因此它拒绝向上转型。然而实际上这根本不是向上转型——Apple的List不是Fruit的List。Apple的List将持有Apple和Apple的子类型，而Fruit的List将持有任何类型的Fruit，诚然，这包括Apple在内，但是它不是一个Apple的List，它仍旧是Fruit的List。Apple的List在类型上不等价于Fruit的List，即使Apple是一种Fruit类型。

真正的问题是我们在谈论容器的类型，而不是容器持有的类型。与数组不同，泛型没有内建的协变类型。这是因为数组在语言中是完全定义的，因此可以内建了编译期和运行时的检査，但是在使用泛型时，编译器和运行时系统都不知道你想用类型做些什么，以及应该来用什么样的规则。

但是，有时你想要在两个类型之间建立某种类型的向上转型关系，这正是通配符所允许的：

class Fruit{}
class Apple extends Fruit{}
public class Test2 {
	public static void main(String[] args) {
		List<? extends Fruit> flist = new LinkedList<Fruit>();
		list.add(null);
		//compile error
		//list.add(new Apple());
	}
}

flist类型现在是List，你可以将其读作“具有任何从Fruit继承的类型的列表”。但是，这实际上并不意味着这个List将持有任何类型的Fruit。通配符引用的是明确的类型，因此它意味着“某种flist引用没有指定的具体类型”。因此这个被赋值的List必须持有诸如Fruit或Apple这样的某种指定类型，但是为了向上转型为flist，这个类型是什么并没有人关心。

如果唯一的限制是这个List要持有某种具体的Fruit或Fruit的子类型，但是你实际上并不关心它是什么，那么你能用这样的List做什么呢？如果不知道List持有什么类型，那么你怎样才能安全地向其中添加对象呢？你不能，除非编译器而不是运行时系统可以阻止这种操作的发生。你很快就会发现这一问题。

你可能会认为，事情变得有点走极端了，因为现在你甚至不能向刚刚声明过将持有Apple对象的List中放置一个Apple对象了。是的，但是编译器并不知道这一点。 List可以合法地指向一个List。一旦执行这种类型的向上转型你就将丢失掉向其中传递任何对象的能力，甚至是传递Object也不行。

另一方面，如果你调用一个返回Fruit的方法，则是安全的，因为你知道在这个List中的任何对象至少具有Fruit类型，因此编译器将允许这么做。

编译器有多聪明

现在，你可能会猜想自己被阻止去调用任何接受参数的方法，但是请考虑下面的程序：

class Fruit{}
class Apple extends Fruit{}
public class Test2 {
	public static void main(String[] args) {
		List<? extends Fruit> flist = Arrays.asList(new Apple());
		flist.indexOf(new Apple());
		flist.contains(new Apple());
		flist.get(0);
	}
}

你可以看到，对contains()和indexOf()的调用，这两个方法都接受Apple对象作为参数，而这些调用都可以正常执行这是否意味着编译器实际上将检査代码，以査看是否有某个特定的方法修改了它的对象？

通过査看ArrayList的文档，我们可以发现，编译器并没有这么聪明。尽管add()将接受一个具有泛型参数类型的参数，但是contains()和indexOf()将接受Object类型的参数。因此当你指定一个ArrayList时，add()的参数就变成了“? Extends Fruit”。从这个描述中，编译器并不能了解这里需要Fruit的哪个具体子类型，因此它不会接受任何类型的Fruit。如果先将Apple向上转型为Fruit，也无关紧要——编译器将直接拒绝对参数列表中涉及通配符的方法（例如add()）的调用。

在使用contains()和indexOf()时，参数类型是Object，因此不涉及任何通配符，而编译器也将允许这个调用。这意味着将由泛型类的设计者来决定哪些调用是“安全的”，并使用Object类型作为其参数类型。为了在类型中使用了通配符的情况下禁止这类调用，我们需要在参数列表中使用类型参数。

逆变

还可以走另外一条路，即使用超类型通配符。这里，可以声明通配符是由某个特定类的任何基类来界定的，方法是指定，甚至或者使用类型参数：（尽管你不能对泛型参数给出一个超类型边界；即不能声明）。这使得你可以安全地传递一个类型对象到泛型类型中。因此，有了超类型通配符，就可以这样写：

class Fruit{}
class Apple extends Fruit{}
public class Test2 {
	static void writeTo(List<? super Apple> list){
		list.add(new Apple());
		list.add(new Fruit());
	}
}

参数Apple是Apple的某种基类型的List，这样你就知道向其中添加Apple或Apple的子类型是安全的。但是，既然Apple是下界，那么你可以知道向这样的List中添加Fruit是不安全的，因为这将使这个List敞开口子，从而可以向其中添加非Apple类型的对象，而这是通反静态类型安全的。

因此你可能会根据如何能够向一个泛型类型“写入”（传递给一个方法），以及如何能够从一个泛型类型中“读取”（从一个方法中返回），来着手思考子类型和超类型边界。

超类型边界放松了在可以向方法传递的参数上所作的限制：

class Fruit{}
class Apple extends Fruit{}
public class Test2 {
	static <T> void writeExact(List<T> list, T item){
		list.add(item);
	}
	static <T> void writeExact2(List<? super T> list, T item){
		list.add(item);
	}
	static List<Fruit> fruit = new ArrayList<Fruit>();
	static List<Apple> apples = new ArrayList<Apple>();
	public static void main(String[] args) {
		writeExact(apples, new Apple());
		writeExact(fruit, new Apple());
		writeExact2(apples, new Apple());
		writeExact2(fruit, new Apple());
	}
}

在writeExact2()中，其参数现在是List，因此这个List将持有从T导出的某种具体类型，这样就可以安全地将一个T类型的对象或者从T导出的任何对象作为参数传递给List的方法。在main()中可以看到这一点，在这个方法中我们仍旧可以像前面那样，将Apple放置到List中，但是现在我们还可以如你所期望的那样，将Apple放置到List中。（注：但是我发现运行上面的的代码并不报错…）

无边界通配符

无界通配符看起来意味着“任何事物”，因此使用无界通配符好像等价于使用原生类型。事实上编译器初看起来是支持这种判断的。

编译器很少关心使用的是原生类型还是。通常可以被认为是一种装饰，但是它仍旧是很有价值的，因为实际上，它是在声明：“我是想用Java的泛型来编写这段代码，我在这里并不是要用原生类型，但是在当前这种情况下, 泛型参数可以持有任何类型。”

下面示例展示了无界通配符的一个重要应用。当你在处理多个泛型参数时，有时允许一个参数可以是任何类型，同时为其他参数确定某种特定类型的这种能力会显得很重要：

public class Test2 {
	static Map map1;
	static Map<?,?> map2;
	static Map<String,?> map3;
	static void assign1(Map map){map1 = map;}
	static void assign2(Map<?,?> map){map2 = map;}
	static void assign3(Map<String,?> map){map3 = map;}
	public static void main(String[] args) {
		assign1(new HashMap());
		assign2(new HashMap());
		assign3(new HashMap());
		assign1(new HashMap<String,Integer>());
		assign2(new HashMap<String,Integer>());
		assign3(new HashMap<String,Integer>());
	}
}

但是，当你相有的全都是无界通配符时，就像在Map中看到的那样，编译器看起来就无法将其与原生Map区分开了。另外，上例展示了编译器处理List和List时是不同的。

令人困惑的是，编译器并非总是关注像List和List之间的这种差异，因此它们看起来就像是相同的事物。因为，事实上，由于泛型参数将擦除到它的第一个边界，因此List看起来等价于List

泛型

泛型