Java深度历险（五）——Java泛型

 

做者 成富 发布于 2011年3月3日 | 注意:QCon全球软件开发大会（北京）2016年4月21-23日，了解更多详情！17 讨论

• 分享到： 微博 微信 Facebook Twitter 有道云笔记 邮件分享
• 稍后阅读
• 个人阅读清单

 

Java泛型（generics）是JDK 5中引入的一个新特性，容许在定义类和接口的时候使用类型参数（type parameter）。声明的类型参数在使用时用具体的类型来替换。泛型最主要的应用是在JDK 5中的新集合类框架中。对于泛型概念的引入，开发社区的观点是褒贬不一。从好的方面来讲，泛型的引入能够解决以前的集合类框架在使用过程当中一般会出现的运行时刻类型错误，由于编译器能够在编译时刻就发现不少明显的错误。而从很差的地方来讲，为了保证与旧有版本的兼容性，Java泛型的实现上存在着一些不够优雅的地方。固然这也是任何有历史的编程语言所须要承担的历史包袱。后续的版本更新会为早期的设计缺陷所累。  

开发人员在使用泛型的时候，很容易根据本身的直觉而犯一些错误。好比一个方法若是接收List<Object>做为形式参数，那么若是尝试将一个List<String>的对象做为实际参数传进去，却发现没法经过编译。虽然从直觉上来讲，Object是String的父类，这种类型转换应该是合理的。可是实际上这会产生隐含的类型转换问题，所以编译器直接就禁止这样的行为。本文试图对Java泛型作一个归纳性的说明。

类型擦除

正确理解泛型概念的首要前提是理解类型擦除（type erasure）。 Java中的泛型基本上都是在编译器这个层次来实现的。在生成的Java字节代码中是不包含泛型中的类型信息的。使用泛型的时候加上的类型参数，会被编译器在编译的时候去掉。这个过程就称为类型擦除。如在代码中定义的List<Object>和List<String>等类型，在编译以后都会变成List。JVM看到的只是List，而由泛型附加的类型信息对JVM来讲是不可见的。Java编译器会在编译时尽量的发现可能出错的地方，可是仍然没法避免在运行时刻出现类型转换异常的状况。类型擦除也是Java的泛型实现方式与C++模板机制实现方式之间的重要区别。

 

相关厂商内容

一路走来技术人的创业故事

将来物联网中智能硬件的角色

人工智能的技术版图

Swift到底能够正式使用了吗？

不要写死！天猫App的动态化配置中心实践

 

相关赞助商

ArchSummit深圳2016将于7月15-16在华侨城洲际大酒店举行，现价8折抢购，团购报名更多优惠！

 

不少泛型的奇怪特性都与这个类型擦除的存在有关，包括：

• 泛型类并无本身独有的Class类对象。好比并不存在List<String>.class或是List<Integer>.class，而只有List.class。
• 静态变量是被泛型类的全部实例所共享的。对于声明为MyClass<T>的类，访问其中的静态变量的方法仍然是 MyClass.myStaticVar。不论是经过new MyClass<String>仍是new MyClass<Integer>建立的对象，都是共享一个静态变量。
• 泛型的类型参数不能用在Java异常处理的catch语句中。由于异常处理是由JVM在运行时刻来进行的。因为类型信息被擦除，JVM是没法区分两个异常类型MyException<String>和MyException<Integer>的。对于JVM来讲，它们都是 MyException类型的。也就没法执行与异常对应的catch语句。

类型擦除的基本过程也比较简单，首先是找到用来替换类型参数的具体类。这个具体类通常是Object。若是指定了类型参数的上界的话，则使用这个上界。把代码中的类型参数都替换成具体的类。同时去掉出现的类型声明，即去掉<>的内容。好比T get()方法声明就变成了Object get()；List<String>就变成了List。接下来就可能须要生成一些桥接方法（bridge method）。这是因为擦除了类型以后的类可能缺乏某些必须的方法。好比考虑下面的代码：

class MyString implements Comparable<String> {
    public int compareTo(String str) {        
        return 0;    
    }
} 

当类型信息被擦除以后，上述类的声明变成了class MyString implements Comparable。可是这样的话，类MyString就会有编译错误，由于没有实现接口Comparable声明的int compareTo(Object)方法。这个时候就由编译器来动态生成这个方法。

 

实例分析

了解了类型擦除机制以后，就会明白编译器承担了所有的类型检查工做。编译器禁止某些泛型的使用方式，正是为了确保类型的安全性。以上面提到的List<Object>和List<String>为例来具体分析：

public void inspect(List<Object> list) {    
    for (Object obj : list) {        
        System.out.println(obj);    
    }    
    list.add(1); //这个操做在当前方法的上下文是合法的。 
}
public void test() {    
    List<String> strs = new ArrayList<String>();    
    inspect(strs); //编译错误 
}  

这段代码中，inspect方法接受List<Object>做为参数，当在test方法中试图传入List<String>的时候，会出现编译错误。假设这样的作法是容许的，那么在inspect方法就能够经过list.add(1)来向集合中添加一个数字。这样在test方法看来，其声明为List<String>的集合中却被添加了一个Integer类型的对象。这显然是违反类型安全的原则的，在某个时候确定会抛出ClassCastException。所以，编译器禁止这样的行为。编译器会尽量的检查可能存在的类型安全问题。对于肯定是违反相关原则的地方，会给出编译错误。当编译器没法判断类型的使用是否正确的时候，会给出警告信息。 

通配符与上下界

在使用泛型类的时候，既能够指定一个具体的类型，如List<String>就声明了具体的类型是String；也能够用通配符?来表示未知类型，如List<?>就声明了List中包含的元素类型是未知的。 通配符所表明的实际上是一组类型，但具体的类型是未知的。List<?>所声明的就是全部类型都是能够的。可是List<?>并不等同于List<Object>。List<Object>实际上肯定了List中包含的是Object及其子类，在使用的时候均可以经过Object来进行引用。而List<?>则其中所包含的元素类型是不肯定。其中可能包含的是String，也多是 Integer。若是它包含了String的话，往里面添加Integer类型的元素就是错误的。正由于类型未知，就不能经过new ArrayList<?>()的方法来建立一个新的ArrayList对象。由于编译器没法知道具体的类型是什么。可是对于 List<?>中的元素确老是能够用Object来引用的，由于虽然类型未知，但确定是Object及其子类。考虑下面的代码：

public void wildcard(List<?> list) {
    list.add(1);//编译错误 
}  

如上所示，试图对一个带通配符的泛型类进行操做的时候，老是会出现编译错误。其缘由在于通配符所表示的类型是未知的。

由于对于List<?>中的元素只能用Object来引用，在有些状况下不是很方便。在这些状况下，可使用上下界来限制未知类型的范围。 如List<? extends Number>说明List中可能包含的元素类型是Number及其子类。而List<? super Number>则说明List中包含的是Number及其父类。当引入了上界以后，在使用类型的时候就可使用上界类中定义的方法。好比访问 List<? extends Number>的时候，就可使用Number类的intValue等方法。

类型系统

在Java中，你们比较熟悉的是经过继承机制而产生的类型体系结构。好比String继承自Object。根据Liskov替换原则，子类是能够替换父类的。当须要Object类的引用的时候，若是传入一个String对象是没有任何问题的。可是反过来的话，即用父类的引用替换子类引用的时候，就须要进行强制类型转换。编译器并不能保证运行时刻这种转换必定是合法的。这种自动的子类替换父类的类型转换机制，对于数组也是适用的。 String[]能够替换Object[]。可是泛型的引入，对于这个类型系统产生了必定的影响。正如前面提到的List<String>是不能替换掉List<Object>的。

引入泛型以后的类型系统增长了两个维度：一个是类型参数自身的继承体系结构，另一个是泛型类或接口自身的继承体系结构。第一个指的是对于 List<String>和List<Object>这样的状况，类型参数String是继承自Object的。而第二种指的是 List接口继承自Collection接口。对于这个类型系统，有以下的一些规则：

• 相同类型参数的泛型类的关系取决于泛型类自身的继承体系结构。即List<String>是Collection<String> 的子类型，List<String>能够替换Collection<String>。这种状况也适用于带有上下界的类型声明。
• 当泛型类的类型声明中使用了通配符的时候， 其子类型能够在两个维度上分别展开。如对Collection<? extends Number>来讲，其子类型能够在Collection这个维度上展开，即List<? extends Number>和Set<? extends Number>等；也能够在Number这个层次上展开，即Collection<Double>和 Collection<Integer>等。如此循环下去，ArrayList<Long>和 HashSet<Double>等也都算是Collection<? extends Number>的子类型。
• 若是泛型类中包含多个类型参数，则对于每一个类型参数分别应用上面的规则。

理解了上面的规则以后，就能够很容易的修正实例分析中给出的代码了。只须要把List<Object>改为List<?>便可。List<String>是List<?>的子类型，所以传递参数时不会发生错误。

开发本身的泛型类

泛型类与通常的Java类基本相同，只是在类和接口定义上多出来了用<>声明的类型参数。一个类能够有多个类型参数，如 MyClass<X, Y, Z>。 每一个类型参数在声明的时候能够指定上界。所声明的类型参数在Java类中能够像通常的类型同样做为方法的参数和返回值，或是做为域和局部变量的类型。可是因为类型擦除机制，类型参数并不能用来建立对象或是做为静态变量的类型。考虑下面的泛型类中的正确和错误的用法。

class ClassTest<X extends Number, Y, Z> {    
    private X x;    
    private static Y y; //编译错误，不能用在静态变量中    
    public X getFirst() {
        //正确用法        
        return x;    
    }    
    public void wrong() {        
        Z z = new Z(); //编译错误，不能建立对象    
    }
}  

最佳实践

在使用泛型的时候能够遵循一些基本的原则，从而避免一些常见的问题。

• 在代码中避免泛型类和原始类型的混用。好比List<String>和List不该该共同使用。这样会产生一些编译器警告和潜在的运行时异常。当须要利用JDK 5以前开发的遗留代码，而不得不这么作时，也尽量的隔离相关的代码。
• 在使用带通配符的泛型类的时候，须要明确通配符所表明的一组类型的概念。因为具体的类型是未知的，不少操做是不容许的。
• 泛型类最好不要同数组一块使用。你只能建立new List<?>[10]这样的数组，没法建立new List<String>[10]这样的。这限制了数组的使用能力，并且会带来不少费解的问题。所以，当须要相似数组的功能时候，使用集合类便可。
• 不要忽视编译器给出的警告信息。

参考资料

• Generics gotchas
• Java Generics FAQs
• Generics in Java Programming Language