Java 中的共变数组和类型擦除

了解泛型

表面上看起来，无论语法还是应用的环境（比如容器类），泛型类型（或者泛型）都类似于 C++ 中的模板。但是这种相似性仅限于表面，Java 语言中的泛型基本上完全在编译器中实现，由编译器执行类型检查和类型推断，然后生成普通的非泛型的字节码。这种实现技术称为擦除（erasure）（编译器使用泛型类型信息保证类型安全，然后在生成字节码之前将其清除），这项技术有一些奇怪，并且有时会带来一些令人迷惑的后果。虽然范型是 Java 类走向类型安全的一大步，但是在学习使用泛型的过程中几乎肯定会遇到头痛（有时候让人无法忍受）的问题。

泛型不是协变的

虽然将集合看作是数组的抽象会有所帮助，但是数组还有一些集合不具备的特殊性质。Java 语言中的数组是协变的（covariant），也就是说，如果 Integer 扩展了 Number（事实也是如此），那么不仅 Integer 是 Number，而且 Integer[] 也是 Number[]，在要求 Number[] 的地方完全可以传递或者赋予 Integer[]。（更正式地说，如果 Number 是 Integer 的超类型，那么 Number[] 也是 Integer[] 的超类型）。

您也许认为这一原理同样适用于泛型类型 —— List<Number> 是 List<Integer> 的超类型，那么可以在需要 List<Number> 的地方传递 List<Integer> 。不幸的是，情况并非如此。

不允许这样做有一个很充分的理由：这样做将破坏要提供的类型安全泛型。如果能够将 List<Integer> 赋给 List<Number> 。那么下面的代码就允许将非 Integer 的内容放入 List<Integer> ：

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));

因为 ln 是 List<Number> ，所以向其添加 Float 似乎是完全合法的。但是如果 ln 是 li 的别名，那么这就破坏了蕴含在 li 定义中的类型安全承诺 —— 它是一个整数列表，这就是泛型类型不能协变的原因。

其他的协变问题

数组能够协变而泛型不能协变的另一个后果是，不能实例化泛型类型的数组（ new List<String>[3] 是不合法的），除非类型参数是一个未绑定的通配符（ new List<?>[3] 是合法的）。让我们看看如果允许声明泛型类型数组会造成什么后果：

List<String>[] lsa = new List<String>[10]; // illegal
Object[] oa = lsa;  // OK because List<String> is a subtype of Object

List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));

oa[0] = li;
String s = lsa[0].get(0);

最后一行将抛出 ClassCastException ，因为这样将把 List<Integer> 填入本应是 List<String> 的位置。因为数组协变会破坏泛型的类型安全，所以不允许实例化泛型类型的数组（除非类型参数是未绑定的通配符，比如 List<?> ）。

构造延迟

因为可以擦除功能，所以 List<Integer> 和 List<String> 是同一个类，编译器在编译 List<V> 时只生成一个类（和 C++ 不同）。因此，在编译 List<V> 类时，编译器不知道 V 所表示的类型，所以它就不能像知道类所表示的具体类型那样处理 List<V> 类定义中的类型参数（ List<V> 中的 V）。

因为运行时不能区分 List<String> 和 List<Integer>（运行时都是 List），用泛型类型参数标识类型的变量的构造就成了问题。运行时缺乏类型信息，这给泛型容器类和希望创建保护性副本的泛型类提出了难题。

比如泛型类 Foo ：

class Foo<T> {
    public void doSomething(T param) { ... }
}

假设 doSomething() 方法希望复制输入的 param 参数，会怎么样呢？没有多少选择。您可能希望按以下方式实现 doSomething() ：

public void doSomething(T param) {
    T copy = new T(param);  // illegal
}

但是您不能使用类型参数访问构造函数，因为在编译的时候还不知道要构造什么类，因此也就不知道使用什么构造函数。使用泛型不能表达 “ T 必须拥有一个拷贝构造函数（copy constructor）”（甚至一个无参数的构造函数）这类约束，因此不能使用泛型类型参数所表示的类的构造函数。

clone() 怎么样呢？假设在 Foo 的定义中，T 扩展了 Cloneable ：

class Foo<T extends Cloneable> {
    public void doSomething(T param) {
        T copy = (T) param.clone();  // illegal
    }
}

不幸的是，仍然不能调用 param.clone() 。为什么呢？因为 clone() 在 Object 中是保护访问的，调用 clone() 必须通过将 clone() 改写公共访问的类引用来完成。但是重新声明 clone() 为 public 并不知道 T，因此克隆也无济于事。

构造通配符引用

因此，不能复制在编译时根本不知道是什么类的类型引用。那么使用通配符类型怎么样？假设要创建类型为 Set<?> 的参数的保护性副本。您知道 Set 有一个拷贝构造函数。而且别人可能曾经告诉过您，如果不知道要设置的内容的类型，最好使用 Set<?> 代替原始类型的 Set，因为这种方法引起的未检查类型转换警告更少。于是，可以试着这样写：

class Foo {
    public void doSomething(Set<?> set) {
        Set<?> copy = new HashSet<?>(set);  // illegal
    }
}

不幸的是，您不能用通配符类型的参数调用泛型构造函数，即使知道存在这样的构造函数也不行。不过您可以这样做：

class Foo {
    public void doSomething(Set<?> set) {
        Set<?> copy = new HashSet<Object>(set);
    }
}

这种构造不那么直观，但它是类型安全的，而且可以像 new HashSet<?>(set) 那样工作。

构造数组

如何实现 ArrayList<V> ？假设类 ArrayList 管理一个 V 数组，您可能希望用 ArrayList<V> 的构造函数创建一个 V 数组：

class ArrayList<V> {
    private V[] backingArray;
        public ArrayList() {
        backingArray = new V[DEFAULT_SIZE]; // illegal
    }
}

但是这段代码不能工作 —— 不能实例化用类型参数表示的类型数组。编译器不知道 V 到底表示什么类型，因此不能实例化 V 数组。

Collections 类通过一种别扭的方法绕过了这个问题，在 Collections 类编译时会产生类型未检查转换的警告。ArrayList 具体实现的构造函数如下：

class ArrayList<V> {
    private V[] backingArray;
    public ArrayList() {
        backingArray = (V[]) new Object[DEFAULT_SIZE];
    }
}

为何这些代码在访问 backingArray 时没有产生 ArrayStoreException 呢？无论如何，都不能将 Object 数组赋给 String 数组。因为泛型是通过擦除实现的，backingArray 的类型实际上就是 Object[]，因为 Object 代替了 V。这意味着：实际上这个类期望 backingArray 是一个 Object 数组，但是编译器要进行额外的类型检查，以确保它包含 V 类型的对象。所以这种方法很奏效，但是非常别扭，因此不值得效仿（甚至连泛型 Collections 框架的作者都这么说）。

还有一种方法就是声明 backingArray 为 Object 数组，并在使用它的各个地方强制将它转化为 V[]。仍然会看到类型未检查转换警告（与上一种方法一样），但是它使一些未明确的假设更清楚了（比如 backingArray 不应逃避 ArrayList 的实现）。

其他方法

最好的办法是向构造函数传递类文字（Foo.class），这样，该实现就能在运行时知道 T 的值。不采用这种方法的原因在于向后兼容性 —— 新的泛型集合类不能与 Collections 框架以前的版本兼容。

下面的代码中 ArrayList 采用了以下方法：

public class ArrayList<V> implements List<V> {
    private V[] backingArray;
    private Class<V> elementType;
    public ArrayList(Class<V> elementType) {
        this.elementType = elementType;
        backingArray = (V[]) Array.newInstance(elementType, DEFAULT_LENGTH);
    }
}

但是等一等！仍然有不妥的地方，调用 Array.newInstance() 时会引起未经检查的类型转换。为什么呢？同样是由于向后兼容性。Array.newInstance() 的签名是：

public static Object newInstance(Class<?> componentType, int length)

而不是类型安全的：

public static<T> T[] newInstance(Class<T> componentType, int length)

为何 Array 用这种方式进行泛化呢？同样是为了保持向后兼容。要创建基本类型的数组，如 int[]，可以使用适当的包装器类中的 TYPE 字段调用 Array.newInstance()（对于 int，可以传递 Integer.TYPE 作为类文字）。用 Class<T> 参数而不是 Class<?> 泛化 Array.newInstance() ，对于引用类型有更好的类型安全，但是就不能使用 Array.newInstance() 创建基本类型数组的实例了。也许将来会为引用类型提供新的 newInstance() 版本，这样就两者兼顾了。

在这里可以看到一种模式 —— 与泛型有关的很多问题或者折衷并非来自泛型本身，而是保持和已有代码兼容的要求带来的副作用。

泛化已有的类

在转化现有的库类来使用泛型方面没有多少技巧，但与平常的情况相同，向后兼容性不会凭空而来。我已经讨论了两个例子，其中向后兼容性限制了类库的泛化。

另一种不同的泛化方法可能不存在向后兼容问题，这就是 Collections.toArray(Object[]) 。传入 toArray() 的数组有两个目的 —— 如果集合足够小，那么可以将其内容直接放在提供的数组中。否则，利用反射（reflection）创建相同类型的新数组来接受结果。如果从头开始重写 Collections 框架，那么很可能传递给 Collections.toArray() 的参数不是一个数组，而是一个类文字：

interface Collection<E> {
    public T[] toArray(Class<T super E> elementClass);
}

因为 Collections 框架作为良好类设计的例子被广泛效仿，但是它的设计受到向后兼容性约束，所以这些地方值得您注意，不要盲目效仿。

首先，常常被混淆的泛型 Collections API 的一个重要方面是 containsAll() 、removeAll() 和 retainAll() 的签名。您可能认为 remove() 和 removeAll() 的签名应该是：

interface Collection<E> {
    public boolean remove(E e);  // not really
    public void removeAll(Collection<? extends E> c);  // not really
}

但实际上却是：

interface Collection<E> {
    public boolean remove(Object o);
    public void removeAll(Collection<?> c);
}

为什么呢？答案同样是因为向后兼容性。x.remove(o) 的接口表明“如果 o 包含在 x 中，则删除它，否则什么也不做。”如果 x 是一个泛型集合，那么 o 不一定与 x 的类型参数兼容。如果 removeAll() 被泛化为只有类型兼容时才能调用（ Collection<? extends E> ），那么在泛化之前，合法的代码序列就会变得不合法，比如：

// a collection of Integers
Collection c = new HashSet();
// a collection of Objects
Collection r = new HashSet();
c.removeAll(r);

如果上述片段用直观的方法泛化（将 c 设为 Collection<Integer>，r 设为 Collection<Object> ），如果 removeAll() 的签名要求其参数为 Collection<? extends E> 而不是 no-op ，那么就无法编译上面的代码。泛型类库的一个主要目标就是不打破或者改变已有代码的语义，因此，必须用比从头重新设计泛型所使用类型约束更弱的类型约束来定义 remove()、removeAll()、retainAll()和 containsAll()。

在泛型之前设计的类可能阻碍了“显然的”泛型化方法。这种情况下就要像上例这样进行折衷，但是如果从头设计新的泛型类，理解 Java 类库中的哪些东西是向后兼容的结果很有意义，这样可以避免不适当的模仿。

擦除的实现

因为泛型基本上都是在 Java 编译器中而不是运行库中实现的，所以在生成字节码的时候，差不多所有关于泛型类型的类型信息都被“擦掉”了。换句话说，编译器生成的代码与您手工编写的不用泛型、检查程序的类型安全后进行强制类型转换所得到的代码基本相同。与 C++ 不同，List<Integer> 和 List<String> 是同一个类（虽然是不同的类型但都是 List<?> 的子类型，与以前的版本相比，在 JDK 5.0 中这是一个更重要的区别）。

擦除意味着一个类不能同时实现 Comparable<String> 和 Comparable<Number> ，因为事实上两者都在同一个接口中，指定同一个 compareTo() 方法。声明 DecimalString 类以便与 String 与 Number 比较似乎是明智的，但对于 Java 编译器来说，这相当于对同一个方法进行了两次声明：

public class DecimalString implements Comparable<Number>, Comparable<String>
{ ... } // nope

擦除的另一个后果是，对泛型类型参数是用强制类型转换或者 instanceof 毫无意义。下面的代码完全不会改善代码的类型安全性：

public <T> T naiveCast(T t, Object o) { return (T) o; }

编译器仅仅发出一个类型未检查转换警告，因为它不知道这种转换是否安全。naiveCast() 方法实际上根本不作任何转换，T 直接被替换为 Object，与期望的相反，传入的对象被强制转换为 Object。

擦除也是造成上述构造问题的原因，即不能创建泛型类型的对象，因为编译器不知道要调用什么构造函数。如果泛型类需要构造用泛型类型参数来指定类型的对象，那么构造函数应该接受类文字（Foo.class）并将它们保存起来，以便通过反射创建实例。

结束语

泛型是 Java 语言走向类型安全的一大步，但是泛型设施的设计和类库的泛化并非未经过妥协。扩展虚拟机指令集来支持泛型被认为是无法接受的，因为这会为 Java 厂商升级其 JVM 造成难以逾越的障碍。因此采用了可以完全在编译器中实现的擦除方法。类似地，在泛型 Java 类库时，保持向后兼容也为类库的泛化方式设置了很多限制，产生了一些混乱的、令人沮丧的结构（如 Array.newInstance()）。这并非泛型本身的问题，而是与语言的演化与兼容有关。但这些也使得泛型学习和应用起来更让人迷惑，更加困难。

泛型的内部原理：类型擦除以及类型擦除带来的问题

Java 的泛型是伪泛型。为什么说 Java 的泛型是伪泛型呢？因为，在编译期间，所有的泛型信息都会被擦除掉。正确理解泛型概念的首要前提是理解类型擦除（type erasure）。 Java 中的泛型基本上都是在编译器这个层次来实现的。在生成的 Java 字节码中是不包含泛型中的类型信息的。使用泛型的时候加上的类型参数，会在编译器在编译的时候去掉。这个过程就称为类型擦除。

Java 泛型的实现方法：类型擦除

Java 的泛型是伪泛型。为什么说 Java 的泛型是伪泛型呢？因为，在编译期间，所有的泛型信息都会被擦除掉。正确理解泛型概念的首要前提是理解类型擦除（type erasure）。

Java 中的泛型基本上都是在编译器这个层次来实现的。在生成的 Java 字节码中是不包含泛型中的类型信息的。使用泛型的时候加上的类型参数，会在编译器在编译的时候去掉。这个过程就称为类型擦除。

如在代码中定义的 List<object> 和 List<String> 等类型，在编译后都会编程 List。JVM 看到的只是 List，而由泛型附加的类型信息对 JVM 来说是不可见的。Java 编译器会在编译时尽可能的发现可能出错的地方，但是仍然无法避免在运行时刻出现类型转换异常的情况。类型擦除也是 Java 的泛型实现方法与 C++ 模版机制实现方式之间的重要区别。

可以通过两个简单的例子，来证明 Java 泛型的类型擦除。

public class Test4 {
    public static void main(String[] args) {
        ArrayList<String> arrayList1=new ArrayList<String>();
        arrayList1.add("abc");
        ArrayList<Integer> arrayList2=new ArrayList<Integer>();
        arrayList2.add(123);
        System.out.println(arrayList1.getClass()==arrayList2.getClass());
    }
}

在这个例子中，我们定义了两个 ArrayList 数组，不过一个是 ArrayList<String> 泛型类型，只能存储字符串。一个是 ArrayList<Integer> 泛型类型，只能存储整形。最后，我们通过 arrayList1 对象和 arrayList2 对象的 getClass 方法获取它们的类的信息，最后发现结果为 true。说明泛型类型 String 和 Integer 都被擦除掉了，只剩下了原始类型。

public class Test4 {
    public static void main(String[] args) throws IllegalArgumentException, SecurityException, IllegalAccessException, InvocationTargetException, NoSuchMethodException {
        ArrayList<Integer> arrayList3=new ArrayList<Integer>();
        arrayList3.add(1);//这样调用add方法只能存储整形，因为泛型类型的实例为Integer
        arrayList3.getClass().getMethod("add", Object.class).invoke(arrayList3, "asd");
        for (int i=0;i<arrayList3.size();i++) {
            System.out.println(arrayList3.get(i));
        }
    }
}

在程序中定义了一个 ArrayList 泛型类型实例化为 Integer 的对象，如果直接调用 add 方法，那么只能存储整形的数据。不过当我们利用反射调用 add 方法的时候，却可以存储字符串。这说明了 Integer 泛型实例在编译之后被擦除了，只保留了原始类型。

类型擦除后保留的原始类型

在上面，两次提到了原始类型，什么是原始类型？原始类型（raw type）就是擦除去了泛型信息，最后在字节码中的类型变量的真正类型。无论何时定义一个泛型类型，相应的原始类型都会被自动地提供。类型变量被擦除 （crased），并使用其限定类型（无限定的变量用 Object）替换。

class Pair<T> {
    private T value;
    public T getValue() {
        return value;
    }
    public void setValue(T  value) {
        this.value = value;
    }
}

Pair<T>的原始类型为：

class Pair {
    private Object value;
    public Object getValue() {
        return value;
    }
    public void setValue(Object  value) {
        this.value = value;
    }
}

因为在 Pair<T> 中，T 是一个无限定的类型变量，所以用 Object 替换。其结果就是一个普通的类，如同泛型加入 Java 变成语言之前已经实现的那样。在程序中可以包含不同类型的 Pair，如 Pair<String> 或 Pair<Integer> ，但是，擦除类型后 它们就成为原始的 Pair 类型了，原始类型都是 Object。

从上面的那个例2中，我们也可以明白 ArrayList<Integer> 被擦除类型后，原始类型也变成了 Object，所以通过反射我们就可以存储字符串了。

如果类型变量有限定，那么原始类型就用第一个边界的类型变量来替换。

比如 Pair 这样声明：

public class Pair<T extends Comparable& Serializable> {
}

那么原始类型就是 Comparable

注意：

如果 Pair 这样声明 public class Pair<T extends Serializable&Comparable> ，那么原始类型就用 Serializable 替换，而编译器在必要的时要向 Comparable 插入强制类型转换。为了提高效率，应该将标签 （tagging）接口（即没有方法的接口）放在边界限定列表的末尾。

要区分原始类型和泛型变量的类型

在调用泛型方法的时候，可以指定泛型，也可以不指定泛型。

在不指定泛型的情况下，泛型变量的类型为该方法中的几种类型的同一个父类的最小级，直到 Object。

在指定泛型的时候，该方法中的几种类型必须是该泛型实例类型或者其子类。

public class Test2{
    public static void main(String[] args) {
        /**不指定泛型的时候*/
        int i=Test2.add(1, 2); //这两个参数都是 Integer，所以 T 为 Integer 类型
        Number f=Test2.add(1, 1.2);//这两个参数一个是 Integer，一个是 Float，所以取同一父类的最小级，为 Number
        Object o=Test2.add(1, "asd");//这两个参数一个是 Integer，一个是 String，所以取同一父类的最小级，为 Object

        /**指定泛型的时候*/
        int a=Test2.<Integer>add(1, 2);//指定了Integer，所以只能为 Integer 类型或者其子类
        int b=Test2.<Integer>add(1, 2.2);//编译错误，指定了 Integer，不能为 Float
        Number c=Test2.<Number>add(1, 2.2); //指定为 Number，所以可以为 Integer 和 Float
    }

    //这是一个简单的泛型方法
    public static <T> T add(T x,T y){
        return y;
    }
}

其实在泛型类中，不指定泛型的时候，也差不多，只不过这个时候的泛型类型为 Object，就比如 ArrayList 中，如果不指定泛型，那么这个 ArrayList 中可以放任意类型的对象。

举例：

public static void main(String[] args) {
    ArrayList arrayList=new ArrayList();
    arrayList.add(1);
    arrayList.add("121");
    arrayList.add(new Date());
}

类型擦除引起的问题及解决方法

因为种种原因，Java 不能实现真正的泛型，只能使用类型擦除来实现伪泛型，这样虽然不会有类型膨胀的问题，但是也引起了许多新的问题。所以，Sun 对这些问题作出了许多限制，避免我们犯各种错误。

先检查，再编译，以及检查编译的对象和引用传递的问题

既然说类型变量会在编译的时候擦除掉，那为什么我们往 ArrayList<String> arrayList=new ArrayList<String>(); 所创建的数组列表 arrayList 中，不能使用 add 方法添加整形呢？不是说泛型变量 Integer 会在编译时候擦除变为原始类型 Object 吗，为什么不能存别的类型呢？既然类型擦除了，如何保证我们只能使用泛型变量限定的类型呢？

Java 是如何解决这个问题的呢？Java 编译器是通过先检查代码中泛型的类型，然后再进行类型擦除，在进行编译的。

举个例子说明：

public static  void main(String[] args) {
    ArrayList<String> arrayList=new ArrayList<String>();
    arrayList.add("123");
    arrayList.add(123);//编译错误
}

在上面的程序中，使用 add 方法添加一个整形，在 eclipse 中，直接就会报错，说明这就是在编译之前的检查。因为如果是在编译之后检查，类型擦除后，原始类型为 Object，是应该运行任意引用类型的添加的。可实际上却不是这样，这恰恰说明了关于泛型变量的使用，是会在编译之前检查的。

那么，这么类型检查是针对谁的呢？我们先看看参数化类型与原始类型的兼容

以 ArrayList 举例子，以前的写法：

ArrayList arrayList=new ArrayList();

现在的写法：

ArrayList<String> arrayList=new ArrayList<String>();

如果是与以前的代码兼容，各种引用传值之间，必然会出现如下的情况：

ArrayList<String> arrayList1=new ArrayList(); //第一种 情况
ArrayList arrayList2=new ArrayList<String>();//第二种 情况

这样是没有错误的，不过会有个编译时警告。

不过在第一种情况，可以实现与完全使用泛型参数一样的效果，第二种则完全没效果。

因为，本来类型检查就是编译时完成的。new ArrayList() 只是在内存中开辟一个存储空间，可以存储任何的类型对象。而真正涉及类型检查的是它的引用，因为我们是使用它引用 arrayList1 来调用它的方法，比如说调用 add() 方法。所以 arrayList1 引用能完成泛型类型的检查。而引用 arrayList2 没有使用泛型，所以不行。

举例：

public class Test10 {
    public static void main(String[] args) {

        ArrayList<String> arrayList1=new ArrayList();
        arrayList1.add("1");//编译通过
        arrayList1.add(1);//编译错误
        String str1=arrayList1.get(0);//返回类型就是String

        ArrayList arrayList2=new ArrayList<String>();
        arrayList2.add("1");//编译通过
        arrayList2.add(1);//编译通过
        Object object=arrayList2.get(0);//返回类型就是Object

        new ArrayList<String>().add("11");//编译通过
        new ArrayList<String>().add(22);//编译错误
        String string=new ArrayList<String>().get(0);//返回类型就是String
    }
}

通过上面的例子，我们可以明白，类型检查就是针对引用的，谁是一个引用，用这个引用调用泛型方法，就会对这个引用调用的方法进行类型检测，而无关它真正引用的对象。

从这里，我们可以再讨论下泛型中参数化类型为什么不考虑继承关系。

在 Java 中，像下面形式的引用传递是不允许的：

ArrayList<String> arrayList1=new ArrayList<Object>();//编译错误
ArrayList<Object> arrayList1=new ArrayList<String>();//编译错误

我们先看第一种情况，将第一种情况拓展成下面的形式：

ArrayList<Object> arrayList1=new ArrayList<Object>();
arrayList1.add(new Object());
arrayList1.add(new Object());
ArrayList<String> arrayList2=arrayList1;//编译错误

实际上，在第 4 行代码的时候，就会有编译错误。那么，我们先假设它编译没错。那么当我们使用 arrayList2 引用 get() 方法取值的时候，返回的都是 String 类型的对象（上面提到了，类型检测是根据引用来决定的。），可是它里面实际上已经被我们存放了 Object 类型的对象，这样，就会有 ClassCastException 了。所以为了避免这种极易出现的错误，Java 不允许进行这样的引用传递。（这也是泛型出现的原因，就是为了解决类型转换的问题，我们不能违背它的初衷）。

在看第二种情况，将第二种情况拓展成下面的形式：

ArrayList<String> arrayList1=new ArrayList<String>();
arrayList1.add(new String());
arrayList1.add(new String());
ArrayList<Object> arrayList2=arrayList1;//编译错误

没错，这样的情况比第一种情况好的多，最起码，在我们用 arrayList2 取值的时候不会出现 ClassCastException ，因为是从 String 转换为 Object。可是，这样做有什么意义呢，泛型出现的原因，就是为了解决类型转换的问题。我们使用了泛型，到头来，还是要自己强转，违背了泛型设计的初衷。所以 Java 不允许这么干。再说，你如果又用 arrayList2 往里面 add() 新的对象，那么到时候取得时候，我怎么知道我取出来的到底是 String 类型的，还是 Object 类型的呢？

所以，要格外注意，泛型中的引用传递的问题。

自动类型转换

因为类型擦除的问题，所以所有的泛型类型变量最后都会被替换为原始类型。这样就引起了一个问题，既然都被替换为原始类型，那么为什么我们在获取的时候，不需要进行强制类型转换呢？看下 ArrayList 和 get 方法：

public E get(int index) {
    RangeCheck(index);
    return (E) elementData[index];
}

看以看到，在 return 之前，会根据泛型变量进行强转。

写了个简单的测试代码：

public class Test {
     public static void main(String[] args) {
          ArrayList<Date> list=new ArrayList<Date>();
          list.add(new Date());
          Date myDate=list.get(0);
     }
}

然后反编了下字节码，如下

public static void main(java.lang.String[]);
Code:
0: new #16 // class java/util/ArrayList
3: dup
4: invokespecial #18 // Method java/util/ArrayList."<init
:()V
7: astore_1
8: aload_1
9: new #19 // class java/util/Date
12: dup
13: invokespecial #21 // Method java/util/Date."<init>":()

16: invokevirtual #22 // Method java/util/ArrayList.add:(L
va/lang/Object;)Z
19: pop
20: aload_1
21: iconst_0
22: invokevirtual #26 // Method java/util/ArrayList.get:(I
java/lang/Object;
25: checkcast #19 // class java/util/Date
28: astore_2
29: return

看第 22 行，它调用的是 ArrayList.get() 方法，方法返回值是 Object，说明类型擦除了。然后第 25 行，它做了一个 checkcast 操作，即检查类型 #19， 在在上面找 #19 引用的类型，他是
9: new #19 // class java/util/Date
是一个 Date 类型，即做 Date 类型的强转。
所以不是在 get 方法里强转的，是在你调用的地方强转的。

附关于 checkcast 的解释：

checkcast checks that the top item on the operand stack (a reference to an object or array) can be cast to a given type. For example, if you write in Java:
return ((String)obj);
then the Java compiler will generate something like:
aload_1 ; push -obj- onto the stack
checkcast java/lang/String ; check its a String
areturn ; return it
checkcast is actually a shortand for writing Java code like:

if (! (obj == null || obj instanceof <class>)) {
throw new ClassCastException();
}
// if this point is reached, then object is either null, or an instance of
// <class> or one of its superclasses.

类型擦除与多态的冲突和解决方法

现在有这样一个泛型类：

class Pair<T> {
    private T value;
    public T getValue() {
        return value;
    }
    public void setValue(T value) {
        this.value = value;
    }
}

然后我们想要一个子类继承它

class DateInter extends Pair<Date> {
    @Override
    public void setValue(Date value) {
        super.setValue(value);
    }
    @Override
    public Date getValue() {
        return super.getValue();
    }
}

在这个子类中，我们设定父类的泛型类型为 Pair<Date> ，在子类中，我们覆盖了父类的两个方法，我们的原意是这样的：

将父类的泛型类型限定为 Date ，那么父类里面的两个方法的参数都为 Date 类型：

public Date getValue() {
    return value;
}
public void setValue(Date value) {
    this.value = value;
}

所以，我们在子类中重写这两个方法一点问题也没有，实际上，从他们的 @Override 标签中也可以看到，一点问题也没有，实际上是这样的吗？

分析：

实际上，类型擦除后，父类的的泛型类型全部变为了原始类型 Object，所以父类编译之后会变成下面的样子：

class Pair {
    private Object value;
    public Object getValue() {
        return value;
    }
    public void setValue(Object  value) {
        this.value = value;
    }
}

再看子类的两个重写的方法的类型：

@Override
public void setValue(Date value) {
    super.setValue(value);
}
@Override
public Date getValue() {
    return super.getValue();
}

先来分析 setValue 方法，父类的类型是 Object ，而子类的类型是 Date，参数类型不一样，这如果实在普通的继承关系中，根本就不会是重写，而是重载。

我们在一个 main 方法测试一下：

public static void main(String[] args) throws ClassNotFoundException {
    DateInter dateInter=new DateInter();
    dateInter.setValue(new Date());
    dateInter.setValue(new Object());//编译错误
}

如果是重载，那么子类中两个 setValue 方法，一个是参数 Object 类型，一个是 Date 类型，可是我们发现，根本就没有这样的一个子类继承自父类的 Object 类型参数的方法。所以说，却是是重写了，而不是重载了。

为什么会这样呢？

原因是这样的，我们传入父类的泛型类型是 Date，Pair<Date> ，我们的本意是将泛型类变为如下：

class Pair {
    private Date value;
    public Date getValue() {
        return value;
    }
    public void setValue(Date value) {
        this.value = value;
    }
}

然后在子类中重写参数类型为 Date 的那两个方法，实现继承中的多态。

可是由于种种原因，虚拟机并不能将泛型类型变为 Date ，只能将类型擦除掉，变为原始类型 Object 。这样，我们的本意是进行重写，实现多态。可是类型擦除后，只能变为了重载。这样，类型擦除就和多态有了冲突。JVM 知道你的本意吗？知道！！！可是它能直接实现吗，不能！！！如果真的不能的话，那 我们怎么去重写我们想要的 Date 类型参数的方法啊。

于是 JVM 采用了一个特殊的方法，来完成这项功能，那就是桥方法。

首先，我们用 javap -c className 的方式反编译下 DateInter 子类的字节码，结果如下：

class com.tao.test.DateInter extends com.tao.test.Pair<java.util.Date> {
  com.tao.test.DateInter();
    Code:
       0: aload_0
       1: invokespecial #8                  // Method com/tao/test/Pair."<init>":()V
       4: return

  public void setValue(java.util.Date);  //我们重写的setValue方法
    Code:
       0: aload_0
       1: aload_1
       2: invokespecial #16                 // Method com/tao/test/Pair.setValue:(Ljava/lang/Object;)V
       5: return

  public java.util.Date getValue();    //我们重写的getValue方法
    Code:
       0: aload_0
       1: invokespecial #23                 // Method com/tao/test/Pair.getValue:()Ljava/lang/Object;
       4: checkcast     #26                 // class java/util/Date
       7: areturn

  public java.lang.Object getValue();     //编译时由编译器生成的桥方法
    Code:
       0: aload_0
       1: invokevirtual #28                 // Method getValue:()Ljava/util/Date 去调用我们重写的getValue方法;
       4: areturn

  public void setValue(java.lang.Object);   //编译时由编译器生成的桥方法
    Code:
       0: aload_0
       1: aload_1
       2: checkcast     #26                 // class java/util/Date
       5: invokevirtual #30                 // Method setValue:(Ljava/util/Date;去调用我们重写的setValue方法)V
       8: return
}

从编译的结果来看，我们本意重写 setValue 和 getValue 方法的子类，竟然有 4 个方法，其实不用惊奇，最后的两个方法，就是编译器自己生成的桥方法。可以看到桥方法的参数类型都是 Object，也就是说，子类中真正覆盖父类两个方法的就是这两个我们看不到的桥方法。而打在我们自己定义的 setvalue 和 getValue 方法上面的 @Oveerride 只不过是假象。而桥方法的内部实现，就只是去调用我们自己重写的那两个方法。

所以，虚拟机巧妙的使用了桥方法，来解决了类型擦除和多态的冲突。

不过，要提到一点，这里面的 setValue 和 getValue 这两个桥方法的意义又有不同。

setValue 方法是为了解决类型擦除与多态之间的冲突。

而 getValue 却有普遍的意义，怎么说呢，如果这是一个普通的继承关系：

那么父类的 setValue 方法如下：

public Object getValue() {
    return super.getValue();
}

而子类重写的方法是：

public Date getValue() {
    return super.getValue();
}

其实这在普通的类继承中也是普遍存在的重写，这就是协变。

并且，还有一点也许会有疑问，子类中的桥方法 Object getValue() 和 Date getValue() 是同时存在的，可是如果是常规的两个方法，他们的方法签名是一样的，也就是说虚拟机根本不能分别这两个方法。如果是我们自己编写Java代码，这样的代码是无 法通过编译器的检查的，但是虚拟机却是允许这样做的，因为虚拟机通过参数类型和返回类型来确定一个方法，所以编译器为了实现泛型的多态允许自己做这个看起来“不合法”的事情，然后交给虚拟器去区别。

泛型类型变量不能是基本数据类型

不能用类型参数替换基本类型。就比如，没有 ArrayList<double>，只有 ArrayList<Double>。因为当类型擦除后，ArrayList 的原始类型变为 Object，但是 Object 类型不能存储 double 值，只能引用 Double 的值。

运行时类型查询

举个例子:

ArrayList<String> arrayList=new ArrayList<String>();

因为类型擦除之后，ArrayList<String> 只剩下原始类型，泛型信息 String 不存在了。那么，运行时进行类型查询的时候使用下面的方法是错误的

if( arrayList instanceof ArrayList<String>)

Java 限定了这种类型查询的方式

if( arrayList instanceof ArrayList<?>)

异常中使用泛型的问题

1、不能抛出也不能捕获泛型类的对象。事实上，泛型类扩展 Throwable 都不合法。例如：下面的定义将不会通过编译：

public class Problem<T> extends Exception{......}

为什么不能扩展 Throwable，因为异常都是在运行时捕获和抛出的，而在编译的时候，泛型信息全都会被擦除掉，那么，假设上面的编译可行，那么，在看下面的定义

try{
    ...
}catch(Problem<Integer> e1){
    ...
}catch(Problem<Number> e2){
    ...
}

类型信息被擦除后，那么两个地方的 catch 都变为原始类型 Object，那么也就是说，这两个地方的 catch 变的一模一样,就相当于下面的这样

try{
    ...
}catch(Problem<Object> e1){
    ...
}catch(Problem<Object> e2){
    ...
}

这个当然就是不行的。就好比，catch 两个一模一样的普通异常，不能通过编译一样：

try{
    ...
}catch(Exception e1){
    ...
}catch(Exception  e2){//编译错误
    ...
}

2、不能再catch子句中使用泛型变量

public static <T extends Throwable> void doWork(Class<T> t){
   try{
        ...
   }catch(T e){ //编译错误
        ...
   }
}

因为泛型信息在编译的时候已经变味原始类型，也就是说上面的 T 会变为原始类型 Throwable，那么如果可以再 catch 子句中使用泛型变量，那么，下面的定义呢：

public static <T extends Throwable> void doWork(Class<T> t){
        try{
            ...
        }catch(T e){ //编译错误
            ...
        }catch(IndexOutOfBounds e){
            ...
        }
 }

根据异常捕获的原则，一定是子类在前面，父类在后面，那么上面就违背了这个原则。即使你在使用该静态方法的使用 T 是 ArrayIndexOutofBounds，在编译之后还是会变成 Throwable，ArrayIndexOutofBounds 是 IndexOutofBounds 的子类，违背了异常捕获的原则。所以 Java 为了避免这样的情况，禁止在 catch 子句中使用泛型变量。

但是在异常声明中可以使用类型变量。下面方法是合法的。

public static<T extends Throwable> void doWork(T t) throws T{
    try{
        ...
    }catch(Throwable realCause){
        t.initCause(realCause);
        throw t;
    }
}

数组（这个不属于类型擦除引起的问题）

不能声明参数化类型的数组。如：

Pair<String>[] table = new Pair<String>(10); //ERROR

这是因为擦除后，table 的类型变为 Pair[]，可以转化成一个 Object[]。

Object[] objarray = table;

数组可以记住自己的元素类型，下面的赋值会抛出一个 ArrayStoreException 异常。

objarray ="Hello"; //ERROR

对于泛型而言，擦除降低了这个机制的效率。下面的赋值可以通过数组存储的检测，但仍然会导致类型错误。

objarray = new Pair<Employee>();

提示：如果需要收集参数化类型对象，直接使用 ArrayList：ArrayList<Pair<String>> 最安全且有效。

泛型类型的实例化

不能实例化泛型类型。如：

first = new T(); //ERROR

是错误的，类型擦除会使这个操作做成 new Object()。

不能建立一个泛型数组。

public<T> T[] minMax(T[] a){
     T[] mm = new T[2]; //ERROR
     ...
}

类似的，擦除会使这个方法总是构靠一个 Object[2] 数组。但是，可以用反射构造泛型对象和数组。

利用反射，调用 Array.newInstance ：

public static <T extends Comparable> T[]minmax(T[] a) {
      T[] mm == (T[])Array.newInstance(a.getClass().getComponentType(),2);
       ...
      // 以替换掉以下代码
      // Obeject[] mm = new Object[2];
      // return (T[]) mm;
}

类型擦除后的冲突

1、当泛型类型被擦除后，创建条件不能产生冲突。如果在 Pair 类中添加下面的 equals 方法：

class Pair<T> {
    public boolean equals(T value) {
        return null;
    }
}

考虑一个 Pair<String>。从概念上，它有两个 equals 方法：

boolean equals(String); //在Pair<T>中定义
boolean equals(Object); //从object中继承

但是，这只是一种错觉。实际上，擦除后方法 boolean equals(T) 变成了方法 boolean equals(Object) 。这与 Object.equals 方法是冲突的！当然，补救的办法是重新命名引发错误的方法。

2、泛型规范说明提及另一个原则 “要支持擦除的转换，需要强行制一个类或者类型变量不能同时成为两个接口的子类，而这两个子类是同一接品的不同参数化。”

下面的代码是非法的：

class Calendar implements Comparable<Calendar>{ ... }
class GregorianCalendar extends Calendar implements Comparable<GregorianCalendar>{...} //ERROR

GregorianCalendar 会实现 Comparable<Calender> 和 Compable<GregorianCalendar> ，这是同一个接口的不同参数化实现。

这一限制与类型擦除的关系并不很明确。非泛型版本：

class Calendar implements Comparable{ ... }
class GregorianCalendar extends Calendar implements Comparable{...} //ERROR

是合法的。

泛型在静态方法和静态类中的问题

泛型类中的静态方法和静态变量不可以使用泛型类所声明的泛型类型参数

举例说明：

public class Test2<T> {
    public static T one;   //编译错误
    public static T show(T one){ //编译错误
        return null;
    }
}

因为泛型类中的泛型参数的实例化是在定义对象的时候指定的，而静态变量和静态方法不需要使用对象来调用。对象都没有创建，如何确定这个泛型参数是何种类型，所以当然是错误的。

但是要注意区分下面的一种情况：

public class Test2<T> {
    public static <T> T show(T one){//这是正确的
        return null;
    }
}

因为这是一个泛型方法，在泛型方法中使用的 T 是自己在方法中定义的 T，而不是泛型类中的 T。

参考

• 了解泛型
• 泛型的内部原理：类型擦除以及类型擦除带来的问题