scala 泛型基础之jdk1.5引入的泛型 generics （一）

最新推荐文章于 2023-03-19 00:29:57 发布

shadowsama

最新推荐文章于 2023-03-19 00:29:57 发布

阅读量368

点赞数

分类专栏： java scala 文章标签： scala

scala 同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

java

3 篇文章 0 订阅

订阅专栏

1. 介绍

JDK1.5中引入了对java语言的多种扩展，泛型(即其中之一。

Generics允许对类型进行抽象(abstract over types)。最常见的例子是集合类型(Container types)，Collection的类树中任意一个即是。

下面是那种典型用法：

List myIntList = new LinkedList();// 1

myIntList.add(new Integer(0));// 2

Integer x = (Integer) myIntList.iterator().next();// 3

第3行的类型转换有些烦人。通常情况下，程序员知道一个特定的list里边放的是什么类型的数据。但是，这个类型转换是必须的(essential)。编译器只能保证iterator返回的是Object类型。为了保证对Integer类型变量赋值的类型安全，必须进行类型转换。

当然，这个类型转换不仅仅带来了混乱，它还可能产生一个运行时错误(run time error)，因为程序员可能会犯错。

程序员如何才能明确表示他们的意图，把一个list中的内容限制为一个特定的数据类型呢？这是generics背后的核心思想。这是上面程序片断的一个泛型版本:

List<Integer> myIntList = new LinkedList<Integer>(); // 1

myIntList.add(new Integer(0)); // 2

Integer x = myIntList.iterator().next(); // 3

注意变量myIntList的类型声明。它指定这不是一个任意的List，而是一个Integer的List，写作：List<Integer>。我们说List是一个带一个类型参数的泛型接口(a generic interface that takes a type parameter)，本例中，类型参数是Integer。我们在创建这个List对象的时候也指定了一个类型参数。

另一个需要注意的是第3行没了类型转换。

现在，你可能认为我们已经成功地去掉了程序里的混乱。我们用第1行的类型参数取代了第3行的类型转换。然而，这里还有个很大的不同。编译器现在能够在编译时检查程序的正确性。当我们说myIntList被声明为List<Integer>类型，这告诉我们无论何时何地使用myIntList变量，编译器保证其中的元素的正确的类型。与之相反，一个类型转换说明程序员认为在那个代码点上它应该是那种类型。

实际结果是，这可以增加可读性和稳定性(robustness)，尤其在大型的程序中。

下面是从java.util包中的List接口和Iterator接口的定义中摘录的片断：

public interface List<E> {

void add(E x);

Iterator<E> iterator();

}

public interface Iterator<E> {

E next();

boolean hasNext();

}

这些都应该是很熟悉的，除了尖括号中的部分，那是接口List和Iterator中的形式类型参数的声明(the declarations of the formal type parameters of the interfaces List and Iterator)。

类型参数在整个类的声明中可用，几乎是所有可是使用其他普通类型的地方(但是有些重要的限制，请参考第7部分)。

（原文：Type parameters can be used throughout the generic declaration, pretty much where you would use ordinary types (though there are some important restrictions; see section 7)）

在介绍那一节我们看到了对泛型类型声明List(the generic type declaration List)的调用，如List<Integer>。在这个调用中(通常称作一个参数化类型a parameterized type)，所有出现形式类型参数(formal type parameter,这里是E)都被替换成实体类型参数(actual type argument)(这里是Integer)。

你可能想象,List<Integer>代表一个E被全部替换成Integer的版本：

public interface IntegerList {

void add(Integer x)

Iterator<Integer> iterator();

}

这种直觉可能有帮助，但是也可能导致误解。

它有帮助，因为List<Integer>的声明确实有类似这种替换的方法。

它可能导致误解，因为泛型声明绝不会实际的被这样替换。没有代码的多个拷贝，源码中没有、二进制代码中也没有；磁盘中没有，内存中也没有。如果你是一个C++程序员，你会理解这是和C++模板的很大的区别。

一个泛型类型的声明只被编译一次，并且得到一个class文件，就像普通的class或者interface的声明一样。

类型参数就跟在方法或构造函数中普通的参数一样。就像一个方法有形式参数(formal value parameters)来描述它操作的参数的种类一样，一个泛型声明也有形式类型参数(formal type parameters)。当一个方法被调用，实参(actual arguments)替换形参，方法体被执行。当一个泛型声明被调用，实际类型参数(actual type arguments)取代形式类型参数。

一个命名的习惯：我们推荐你用简练的名字作为形式类型参数的名字(如果可能，单个字符)。最好避免小写字母，这使它和其他的普通的形式参数很容易被区分开来。许多容器类型使用E作为其中元素的类型，就像上面举的例子。在后面的例子中还会有一些其他的命名习惯。

3. 让我们测试一下我们对泛型的理解。下面的代码片断合法么？

List<String> ls = new ArrayList<String>(); //1

List<Object> lo = ls; //2

第1行当然合法，但是这个问题的狡猾之处在于第2行。

这产生一个问题：

一个String的List是一个Object的List么？大多数人的直觉是回答：“当然！”。

好，在看下面的几行：

lo.add(new Object()); // 3

String s = ls.get(0); // 4: 试图把Object赋值给String

这里，我们使用lo指向ls。我们通过lo来访问ls,一个String的list。我们可以插入任意对象进去。结果是ls中保存的不再是String。当我们试图从中取出元素的时候，会得到意外的结果。

java编译器当然会阻止这种情况的发生。第2行会导致一个编译错误。

总之，如果Foo是Bar的一个子类型(子类或者子接口)，而G是某种泛型声明，那么G<Foo>是G<Bar>的子类型并不成立!!

这可能是你学习泛型中最难理解的部分，因为它和你的直觉相反。

这种直觉的问题在于它假定这个集合不改变。我们的直觉认为这些东西都不可改变。

举例来说，如果一个交通部(DMV)提供一个驾驶员里表给人口普查局，这似乎很合理。我们想，一个List<Driver>是一个List<Person>，假定Driver是Person的子类型。实际上，我们传递的是一个驾驶员注册的拷贝。然而，人口普查局可能往驾驶员list中加入其他人，这破坏了交通部的记录。

为了处理这种情况，考虑一些更灵活的泛型类型很有用。到现在为止我们看到的规则限制比较大。

4. 通配符(Wildcards)

考虑写一个例程来打印一个集合(Collection)中的所有元素。下面是在老的语言中你可能写的代码：

void printCollection(Collection c) {

Iterator i = c.iterator();

for (int k = 0; k < c.size(); k++) {

System.out.println(i.next());

}

下面是一个使用泛型的幼稚的尝试(使用了新的循环语法):

void printCollection(Collection<Object> c) {

for (Object e : c) {

System.out.println(e);

}

问题是新版本的用处比老版本小多了。老版本的代码可以使用任何类型的collection作为参数，而新版本则只能使用Collection<Object>，我们刚才阐述了，它不是所有类型的collections的父类。

那么什么是各种collections的父类呢？它写作： Collection<?>(发音为:"collection of unknown")，就是，一个集合，它的元素类型可以匹配任何类型。显然，它被称为通配符。我们可以写：

void printCollection(Collection<?> c) {

for (Object e : c) {

System.out.println(e);

}

现在，我们可以使用任何类型的collection来调用它。注意，我们仍然可以读取c中的元素，其类型是Object。这永远是安全的，因为不管collection的真实类型是什么，它包含的都是objects。但是将任意元素加入到其中不是类型安全的：

Collection<?> c = new ArrayList<String>();

c.add(new Object()); // 编译时错误

因为我们不知道c的元素类型，我们不能向其中添加对象。

add方法有类型参数E作为集合的元素类型。我们传给add的任何参数都必须是一个未知类型的子类。因为我们不知道那是什么类型，所以我们无法传任何东西进去。唯一的例外是null，它是所有类型的成员。

另一方面，我们可以调用get()方法并使用其返回值。返回值是一个未知的类型，但是我们知道，它总是一个Object，因此把get的返回值赋值给一个Object类型的对象或者放在任何希望是Object类型的地方是安全的。

4.1. 有限制的通配符(Bounded Wildcards)

考虑一个简单的画图程序，它可以用来画各种形状，比如矩形和圆形。

为了在程序中表示这些形状，你可以定义下面的类继承结构：

public abstract class Shape {

public abstract void draw(Canvas c);

}

public class Circle extends Shape {

private int x, y, radius;

public void draw(Canvas c) { // ...

}

public class Rectangle extends Shape {

private int x, y, width, height;

public void draw(Canvas c) {

// ...

}

这些类可以在一个画布(Canvas)上被画出来:

public class Canvas {

public void draw(Shape s) {

s.draw(this);

}

所有的图形通常都有很多个形状。假定它们用一个list来表示，Canvas里有一个方法来画出所有的形状会比较方便：

public void drawAll(List<Shape> shapes) {

for (Shape s : shapes) {

s.draw(this);

}

现在，类型规则导致drawAll()只能使用Shape的list来调用。它不能，比如说对List<Circle>来调用。这很不幸，因为这个方法所作的只是从这个list读取shape，因此它应该也能对List<Circle>调用。我们真正要的是这个方法能够接受一个任意种类的shape:

public void drawAll(List<? extends Shape> shapes) { //..}

这里有一处很小但是很重要的不同:我们把类型 List<Shape> 替换成了 List<? extends Shape>。现在drawAll()可以接受任何Shape的子类的List，所以我们可以对List<Circle>进行调用。

List<? extends Shape>是有限制通配符的一个例子。这里？代表一个未知的类型，就像我们前面看到的通配符一样。但是，在这里，我们知道这个未知的类型实际上是Shape的一个子类(它可以是Shape本身或者Shape的子类而不必是extends自Shape)。我们说Shape是这个通配符的上限(upper bound)。

像平常一样，要得到使用通配符的灵活性有些代价。这个代价是，现在像shapes中写入是非法的。比如下面的代码是不允许的：

public void addRectangle(List<? extends Shape> shapes) {

shapes.add(0, new Rectangle()); // compile-time error!

}

你应该能够指出为什么上面的代码是不允许的。因为shapes.add的第二个参数类型是? extends Shape ——一个Shape未知的子类。因此我们不知道这个类型是什么，我们不知道它是不是Rectangle的父类；它可能是也可能不是一个父类，所以这里传递一个Rectangle不安全。

有限制的通配符正是我们解决DMV给人口普查局传送名单的例子所需要的。我们的例子假定数据用一个姓名（String）到people（用Person或其子类来表示，比如Driver）。Map<K,V>是一个有两个类型参数的泛型类型的例子，表示map的键key和值value。

再一次，注意形式类型参数的命名习惯——K代表keys，V代表vlaues。

public class Census {

public static void addRegistry(Map<String, ? extends Person> registry) { ...}

}...

Map<String, Driver> allDrivers = ...;

Census.addRegistry(allDrivers);

5. 泛型方法

考虑写一个方法，它用一个Object的数组和一个collection作为参数，完成把数组中所有object放入collection中的功能。

下面是第一次尝试：

static void fromArrayToCollection(Object[] a, Collection<?> c) {

for (Object o : a) {

c.add(o); // 编译期错误

}

现在，你应该能够学会避免初学者试图使用Collection<Object>作为集合参数类型的错误了。或许你已经意识到使用 Collection<?>也不能工作。会议一下，你不能把对象放进一个未知类型的集合中去。

解决这个问题的办法是使用generic methods。就像类型声明，方法的声明也可以被泛型化——就是说，带有一个或者多个类型参数。

static <T> void fromArrayToCollection(T[] a, Collection<T> c){

for (T o : a) {

c.add(o); // correct

}

我们可以使用任意集合来调用这个方法，只要其元素的类型是数组的元素类型的父类。

Object[] oa = new Object[100];

Collection<Object> co = new ArrayList<Object>();

fromArrayToCollection(oa, co);// T 指Object

String[] sa = new String[100];

Collection<String> cs = new ArrayList<String>();

fromArrayToCollection(sa, cs);// T inferred to be String

fromArrayToCollection(sa, co);// T inferred to be Object

Integer[] ia = new Integer[100];

Float[] fa = new Float[100];

Number[] na = new Number[100];

Collection<Number> cn = new ArrayList<Number>();

fromArrayToCollection(ia, cn);// T inferred to be Number

fromArrayToCollection(fa, cn);// T inferred to be Number

fromArrayToCollection(na, cn);// T inferred to be Number

fromArrayToCollection(na, co);// T inferred to be Object

fromArrayToCollection(na, cs);// compile-time error

注意，我们并没有传送真实类型参数(actual type argument)给一个泛型方法。编译器根据实参为我们推断类型参数的值。它通常推断出能使调用类型正确的最明确的类型参数(原文是：It will generally infer the most specific type argument that will make the call type-correct.)。

现在有一个问题：我们应该什么时候使用泛型方法，又什么时候使用通配符类型呢？

为了理解答案，让我们先看看Collection库中的几个方法。

public interface Collection<E> {

boolean containsAll(Collection<?> c);

boolean addAll(Collection<? extends E> c);

}

我们也可以使用泛型方法来代替：

public interface Collection<E> {

<T> boolean containsAll(Collection<T> c);

<T extends E> boolean addAll(Collection<T> c);

// hey, type variables can have bounds too!

}

但是，在 containsAll 和 addAll中，类型参数T 都只使用一次。返回值的类型既不依赖于类型参数(type parameter)也不依赖于方法的其他参数（这里，只有简单的一个参数）。这告诉我们类型参数(type argument)被用作多态（polymorphism），它唯一的效果是允许在不同的调用点，可以使用多种实参类型(actual argument)。如果是这种情况，应该使用通配符。通配符就是被设计用来支持灵活的子类化的，这是我们在这里要强调的。

泛型函数允许类型参数被用来表示方法的一个或多个参数之间的依赖关系，或者参数与其返回值的依赖关系。如果没有这样的依赖关系，不应该使用泛型方法。

(原文：Generic methods allow type parameters to be used to express dependencies among the types of one or morearguments to a method and/or its return type. If there isn’t such a dependency, a generic method should not be used.）

一前一后的同时使用泛型方法和通配符也是可能的。下面是方法 Collections.copy():

class Collections {

public static <T> void copy(List<T> dest, List<? extends T> src){...}

}

注意两个参数的类型的依赖关系。任何被从源list从拷贝出来的对象必须能够将其指定为目标list(dest) 的元素的类型——T类型。因此源类型的元素类型可以是T的任意子类型，我们不关心具体的类型。

copy方法的签名使用一个类型参数表示了类型依赖，但是使用了一个通配符作为第二个参数的元素类型。我们也可以用其他方式写这个函数的签名而根本不使用通配符：

class Collections {

public static <T, S extends T> void copy(List<T> dest, List<S> src){...}

}

这也可以，但是第一个类型参数在dst的类型和第二个参数的类型参数S的上限这两个地方都有使用，而S本身只使用一次，在src的类型中——没有其他的依赖于它。这意味着我们可以用通配符来代替S。使用通配符比声明显式的类型参数更加清晰和准确，所以在可能的情况下使用通配符更好。

通配符还有一个优势式他们可以在方法签名之外被使用，比如field的类型，局部变量和数组。这就有一个例子。

回到我们的画图问题，假定我们想要保持画图请求的历史记录。我们可以把历史记录保存在Shape类的一个静态成员变量里，在drawAll() 被调用的时候把传进来的参数保存进历史记录：

static List<List<? extends Shape>> history = new ArrayList<List<? extends Shape>>();

public void drawAll(List<? extends Shape> shapes) {

history.addLast(shapes);

for (Shape s: shapes) {

s.draw(this);

}

最终，再说一下类型参数的命名习惯。

我们使用T 代表类型，无论何时都没有比这更具体的类型来区分它。这经常见于泛型方法。如果有多个类型参数，我们可能使用字母表中T的临近的字母，比如S。如果一个泛型函数在一个泛型类里边出现，最好避免在方法的类型参数和类的类型参数中使用同样的名字来避免混淆。对内部类也是同样。

Java泛型－类型擦除

一、概述

Java泛型在使用过程有诸多的问题，如不存在List<String>.class, List<Integer>不能赋值给List<Number>（不可协变），奇怪的ClassCastException等。正确的使用Java泛型需要深入的了解Java的一些概念，如协变，桥接方法，以及这篇笔记记录的类型擦除。Java泛型的处理几乎都在编译器中进行，编译器生成的bytecode是不包涵泛型信息的，泛型类型信息将在编译处理是被擦除，这个过程即类型擦除。

二、编译器如何处理泛型？

     通常情况下，一个编译器处理泛型有两种方式：
   1.Code specialization。在实例化一个泛型类或泛型方法时都产生一份新的目标代码（字节码or二进制代码）。例如，针对一个泛型list，可能需要针对string，integer，float产生三份目标代码。
   2.Code sharing。对每个泛型类只生成唯一的一份目标代码；该泛型类的所有实例都映射到这份目标代码上，在需要的时候执行类型检查和类型转换。
   C++中的模板（template）是典型的Code specialization实现。C++编译器会为每一个泛型类实例生成一份执行代码。执行代码中integer list和string list是两种不同的类型。这样会导致代码膨胀（code bloat），不过有经验的C＋＋程序员可以有技巧的避免代码膨胀。
   Code specialization另外一个弊端是在引用类型系统中，浪费空间，因为引用类型集合中元素本质上都是一个指针。没必要为每个类型都产生一份执行代码。而这也是Java编译器中采用Code sharing方式处理泛型的主要原因。
   Java编译器通过Code sharing方式为每个泛型类型创建唯一的字节码表示，并且将该泛型类型的实例都映射到这个唯一的字节码表示上。将多种泛型类形实例映射到唯一的字节码表示是通过类型擦除（type erasue）实现的。

三、什么是类型擦除？

     类型擦除指的是通过类型参数合并，将泛型类型实例关联到同一份字节码上。编译器只为泛型类型生成一份字节码，并将其实例关联到这份字节码上。类型擦除的关键在于从泛型类型中清除类型参数的相关信息，并且再必要的时候添加类型检查和类型转换的方法。
     类型擦除可以简单的理解为将泛型java代码转换为普通java代码，只不过编译器更直接点，将泛型java代码直接转换成普通java字节码。
     类型擦除的主要过程如下：
   1.将所有的泛型参数用其最左边界（最顶级的父类型）类型替换。
   2.移除所有的类型参数。
     如
interface Comparable <A> {
public int compareTo( A that);
}
final class NumericValue implements Comparable <NumericValue> {
priva te byte value;
public  NumericValue (byte value) { this.value = value; }
public byte getValue() { return value; }
public int compareTo( NumericValue t hat) { return this.value - that.value; }
}
－－－－－－－－－－－－－－－－－
class Collections {
public static <A extends Comparable<A>>A max(Collection <A> xs) {
    Iterator <A> xi = xs.iterator();
    A w = xi.next();
    while (xi.hasNext()) {
      A x = xi.next();
      if (w.compareTo(x) < 0) w = x;
    }
    return w;
}
}
final class Test {
public static void main (String[ ] args) {
    LinkedList <NumericValue> numberList = new LinkedList <NumericValue> ();
    numberList .add(new NumericValue((byte)0));
    numberList .add(new NumericValue((byte)1));
    NumericValue y = Collections.max( numberList );
}
}
经过类型擦除后的类型为
interface Comparable {
public int compareTo( Object that);
}
final class NumericValue implements Comparable {
priva te byte value;
public  NumericValue (byte value) { this.value = value; }
public byte getValue() { return value; }
public int compareTo( NumericValue t hat)   { return this.value - that.value; }
  public int compareTo(Object that) { return this.compareTo((NumericValue)that); }
}
－－－－－－－－－－－－－
class Collections {
public static Comparable max(Collection xs) {
    Iterator xi = xs.iterator();
    Comparable w = (Comparable) xi.next();
    while (xi.hasNext()) {
      Comparable x = (Comparable) xi.next();
      if (w.compareTo(x) < 0) w = x;
    }
    return w;
}
}
final class Test {
public static void main (String[ ] args) {
    LinkedList numberList = new LinkedList();
    numberList .add(new NumericValue((byte)0));  ，
    numberList .add(new NumericValue((byte)1));
    NumericValue y = (NumericValue) Collections.max( numberList );
}
}
第一个泛型类Comparable <A>擦除后 A被替换为最左边界Object。Comparable<NumericValue>的类型参数NumericValue被擦除掉，但是这直接导致NumericValue没有实现接口Comparable的compareTo(Object that)方法，于是编译器充当好人，添加了一个桥接方法。
第二个示例中限定了类型参数的边界<A extends Comparable<A>>A，A必须为Comparable<A>的子类，按照类型擦除的过程，先讲所有的类型参数 ti换为最左边界Comparable<A>，然后去掉参数类型A，得到最终的擦除后结果。

四、类型擦除带来的问题

     正是由于类型擦除的隐蔽存在，直接导致了众多的泛型灵异问题。
Q1.用同一泛型类的实例区分方法签名？——NO！
    import java.util.*;

    public class Erasure{

            public void test(List<String> ls){
                System.out.println("Sting");
            }
            public void test(List<Integer> li){
                System.out.println("Integer");
            }
    }
编译该类，

参数类型明明不一样啊，一个List<String>，一个是List<Integer>，但是，偷偷的说，type erasure之后，它就都是List了⋯⋯
Q2. 同时catch同一个泛型异常类的多个实例？——NO！
同理，如果定义了一个泛型一场类GenericException<T>，千万别同时catch GenericException<Integer> 和GenericException<String>，因为他们是一样一样滴⋯⋯
Q3.泛型类的静态变量是共享的？——Yes！
猜猜这段代码的输出是什么？
import java.util.*;

public class StaticTest{
    public static void main(String[] args){
        GT<Integer> gti = new GT<Integer>();
        gti.var=1;
        GT<String> gts = new GT<String>();
        gts.var=2;
        System.out.println(gti.var);
    }
}
class GT<T>{
    public static int var=0;
    public void nothing(T x){}
}
答案是——2！由于经过类型擦除，所有的泛型类实例都关联到同一份字节码上，泛型类的所有静态变量是共享的。

五、Just remember

1.虚拟机中没有泛型，只有普通类和普通方法
2.所有泛型类的类型参数在编译时都会被擦除
3.创建泛型对象时请指明类型，让编译器尽早的做参数检查（Effective Java，第23条：请不要在新代码中使用原生态类型）
4.不要忽略编译器的警告信息，那意味着潜在的ClassCastException等着你。