自Java 5以来，泛型已经成为该语言的一部分。在泛型之前，你必须转换从集合中读取的每个对象。如果有人不小心插入了错误类型的对象，则在运行时可能会失败。使用泛型，你告诉编译器在每个集合中允许哪些类型的对象。编译器会自动插入强制转换，并在编译时告诉你是否尝试插入错误类型的对象。这样做的结果是既安全又清晰的程序，但这些益处，不限于集合，是有代价的。本章告诉你如何最大限度地提高益处，并将并发症降至最低。

26. 不要使用原始类型

首先，有几个术语。一个类或接口，它的声明有一个或多个类型参数（ type parameters ），被称之为泛型类或泛型接口[JLS，8.1.2,9.1.2]。例如，List接口具有单个类型参数E，表示其元素类型。接口的全名是List<E>（读作“E”的列表），但是人们经常称它为List。泛型类和接口统称为泛型类型（generic types）。

每个泛型定义了一组参数化类型（parameterized types），它们由类或接口名称组成，后跟一个与泛型类型的形式类型参数[JLS，4.4,4.5]相对应的实际类型参数的尖括号“<>”列表。例如，List<String>（读作“字符串列表”）是一个参数化类型，表示其元素类型为String的列表。（String是与形式类型参数E相对应的实际类型参数）。

最后，每个泛型定义了一个原始类型（ raw type），它是没有任何类型参数的泛型类型的名称[JLS，4.8]。例如，对应于List<E>的原始类型是List。原始类型的行为就像所有的泛型类型信息都从类型声明中被清除一样。它们的存在主要是为了与没有泛型之前的代码相兼容。

在泛型被添加到Java之前，这是一个典型的集合声明。从Java 9开始，它仍然是合法的，但并不是典型的声明方式了：

// Raw collection type - don't do this!
// My stamp collection. Contains only Stamp instances.
private final Collection stamps = ... ;

如果你今天使用这个声明，然后不小心把coin实例放入你的stamp集合中，错误的插入编译和运行没有错误（尽管编译器发出一个模糊的警告）：

// Erroneous insertion of coin into stamp collection
stamps.add(new Coin( ... )); // Emits "unchecked call" warning

直到您尝试从stamp集合中检索coin实例时才会发生错误：

// Raw iterator type - don't do this!
for (Iterator i = stamps.iterator(); i.hasNext(); )
    Stamp stamp = (Stamp) i.next(); // Throws ClassCastException
        stamp.cancel();

正如本书所提到的，在编译完成之后尽快发现错误是值得的，理想情况是在编译时。在这种情况下，直到运行时才发现错误，在错误发生后的很长一段时间，以及可能远离包含错误的代码的代码中。一旦看到ClassCastException，就必须搜索代码类库，查找将coin实例放入stamp集合的方法调用。编译器不能帮助你，因为它不能理解那个说“仅包含stamp实例”的注释。

对于泛型，类型声明包含的信息，而不是注释：

// Parameterized collection type - typesafe
private final Collection<Stamp> stamps = ... ;

从这个声明中，编译器知道stamps集合应该只包含Stamp实例，并保证它是true，假设你的整个代码类库编译时不发出（或者抑制;参见条目27）任何警告。当使用参数化类型声明声明stamps时，错误的插入会生成一个编译时错误消息，告诉你到底发生了什么错误：

Test.java:9: error: incompatible types: Coin cannot be converted
to Stamp
    c.add(new Coin());
              ^

当从集合中检索元素时，编译器会为你插入不可见的强制转换，并保证它们不会失败（再假设你的所有代码都不会生成或禁止任何编译器警告）。虽然意外地将coin实例插入stamp集合的预期可能看起来很牵强，但这个问题是真实的。例如，很容易想象将BigInteger放入一个只包含BigDecimal实例的集合中。

如前所述，使用原始类型（没有类型参数的泛型）是合法的，但是你不应该这样做。 如果你使用原始类型，则会丧失泛型的所有安全性和表达上的优势。鉴于你不应该使用它们，为什么语言设计者首先允许原始类型呢？答案是为了兼容性。泛型被添加时，Java即将进入第二个十年，并且有大量的代码没有使用泛型。所有这些代码都是合法的，并且与使用泛型的新代码进行交互操作被认为是至关重要的。将参数化类型的实例传递给为原始类型设计的方法必须是合法的，反之亦然。这个需求，被称为迁移兼容性，驱使决策支持原始类型，并使用擦除来实现泛型（条目 28）。

虽然不应使用诸如List之类的原始类型，但可以使用参数化类型来允许插入任意对象（如List<Object>）。原始类型List和参数化类型List<Object>之间有什么区别？松散地说，前者已经选择了泛型类型系统，而后者明确地告诉编译器，它能够保存任何类型的对象。虽然可以将List<String>传递给List类型的参数，但不能将其传递给List<Object>类型的参数。泛型有子类型的规则，List<String>是原始类型List的子类型，但不是参数化类型List<Object>的子类型（条目 28）。因此，如果使用诸如List之类的原始类型，则会丢失类型安全性，但是如果使用参数化类型（例如List <Object>）则不会。

为了具体说明，请考虑以下程序：

// Fails at runtime - unsafeAdd method uses a raw type (List)!
public static void main(String[] args) {
    List<String> strings = new ArrayList<>();
    unsafeAdd(strings, Integer.valueOf(42));
    String s = strings.get(0); // Has compiler-generated cast
}
private static void unsafeAdd(List list, Object o) {
    list.add(o);
}

此程序可以编译，它使用原始类型列表，但会收到警告：

Test.java:10: warning: [unchecked] unchecked call to add(E) as a
member of the raw type List
    list.add(o);
            ^

实际上，如果运行该程序，则当程序尝试调用strings.get(0)的结果（一个Integer）转换为一个String时，会得到ClassCastException异常。这是一个编译器生成的强制转换，因此通常会保证成功，但在这种情况下，我们忽略了编译器警告并付出了代价。

如果用unsafeAdd声明中的参数化类型List <Object>替换原始类型List，并尝试重新编译该程序，则会发现它不再编译，而是发出错误消息：

Test.java:5: error: incompatible types: List<String> cannot be
converted to List<Object>
    unsafeAdd(strings, Integer.valueOf(42));

你可能会试图使用原始类型来处理元素类型未知且无关紧要的集合。例如，假设你想编写一个方法，它需要两个集合并返回它们共同拥有的元素的数量。如果是泛型新手，那么您可以这样写：

// Use of raw type for unknown element type - don't do this!
static int numElementsInCommon(Set s1, Set s2) {
    int result = 0;
    for (Object o1 : s1)
        if (s2.contains(o1))
            result++;
    return result;
}

这种方法可以工作，但它使用原始类型，这是危险的。安全替代方式是使用无限制通配符类型（unbounded wildcard types）。如果要使用泛型类型，但不知道或关心实际类型参数是什么，则可以使用问号来代替。例如，泛型类型Set<E>的无限制通配符类型是Set <?>（读取“某种类型的集合”）。它是最通用的参数化的Set类型，能够保持任何集合。下面是numElementsInCommon方法使用无限制通配符类型声明的情况：

// Uses unbounded wildcard type - typesafe and flexible
static int numElementsInCommon(Set<?> s1, Set<?> s2) { ... }
复制代码

无限制通配符Set <?>与原始类型Set之间有什么区别？问号真的给你放任何东西吗？这不是要点，但通配符类型是安全的，原始类型不是。你可以将任何元素放入具有原始类型的集合中，轻易破坏集合的类型不变性（如第119页上的unsafeAdd方法所示）; 你不能把任何元素（除null之外）放入一个Collection <?>中。试图这样做会产生一个像这样的编译时错误消息：

WildCard.java:13: error: incompatible types: String cannot be
converted to CAP#1
    c.add("verboten");
          ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?

不可否认的是，这个错误信息留下了一些需要的东西，但是编译器已经完成了它的工作，不管它的元素类型是什么，都不会破坏集合的类型不变性。你不仅可以将任何元素（除null以外）放入一个Collection <?>中，但是不能保证你所得到的对象的类型。如果这些限制是不可接受的，可以使用泛型方法（条目 30）或有限制配符类型（条目 31）。

对于不应该使用原始类型的规则，有一些小例外。 你必须在类字面值（class literals）中使用原始类型。规范中不允许使用参数化类型（尽管它允许数组类型和基本类型）[JLS，15.8.2]。换句话说，List.class，String [] .class和int.class都是合法的，但List <String> .class和List <?>.class不是合法的。

规则的第二个例外涉及instanceof操作符。因为泛型类型信息在运行时被删除，所以在无限制通配符类型以外的参数化类型上使用instanceof运算符是非法的。使用无限制通配符类型代替原始类型不会以任何方式影响instanceof运算符的行为。在这种情况下，尖括号和问号就显得多余。以下是使用泛型类型的instanceof运算符的首选方法：

// Legitimate use of raw type - instanceof operator
if (o instanceof Set) {       // Raw type
    Set<?> s = (Set<?>) o;    // Wildcard type
    ...
}

请注意，一旦确定o对象是一个Set，则必须将其转换为通配符Set <?>，而不是原始类型Set。这是一个强制转换，所以不会导致编译器警告。

总之，使用原始类型可能导致运行时异常，所以不要使用它们。它们仅用于与泛型引入之前的传统代码的兼容性和互操作性。作为一个快速回顾，Set<Object>是一个参数化类型，表示一个可以包含任何类型对象的集合，Set<?>是一个通配符类型，表示一个只能包含某些未知类型对象的集合，Set是一个原始类型，它不在泛型类型系统之列。前两个类型是安全的，最后一个不是。

为了快速参考，下表中总结了本条目（以及本章稍后介绍的一些）中介绍的术语：

术语

中文含义

举例

所在条目

Parameterized type

参数化类型

List<String>

条目 26

Actual type parameter

实际类型参数

String

条目 26

Generic type

泛型类型

List<E>

条目 26

Formal type parameter

形式类型参数

E

条目 26

Unbounded wildcard type

无限制通配符类型

List<?>

条目 26

Raw type

原始类型

List

条目 26

Bounded type parameter

限制类型参数

<E extends Number>

条目 29

Recursive type bound

递归类型限制

<T extends Comparable<T>>

条目 30

Bounded wildcard type

限制通配符类型

List<? extends Number>

条目 31

Generic method

泛型方法

static <E> List<E> asList(E[] a)

条目 30

Type token

类型令牌

String.class

条目 33

27. 消除非检查警告

使用泛型编程时，会看到许多编译器警告：未经检查的强制转换警告，未经检查的方法调用警告，未经检查的参数化可变长度类型警告以及未经检查的转换警告。你使用泛型获得的经验越多，获得的警告越少，但不要期望新编写的代码能够干净地编译。

许多未经检查的警告很容易消除。例如，假设你不小心写了以下声明：

Set<Lark> exaltation = new HashSet();

编译器会提醒你你做错了什么：

Venery.java:4: warning: [unchecked] unchecked conversion
        Set<Lark> exaltation = new HashSet();
                               ^
  required: Set<Lark>
  found:    HashSet

然后可以进行指示修正，让警告消失。请注意，实际上并不需要指定类型参数，只是为了表明它与Java 7中引入的钻石运算符（"<>"）一同出现。然后编译器会推断出正确的实际类型参数（在本例中为Lark）：

Set<Lark> exaltation = new HashSet<>();

但一些警告更难以消除。本章充满了这种警告的例子。当你收到需要进一步思考的警告时，坚持不懈！ 尽可能地消除每一个未经检查的警告。如果你消除所有的警告，你可以放心，你的代码是类型安全的，这是一件非常好的事情。这意味着在运行时你将不会得到一个ClassCastException异常，并且增加了你的程序将按照你的意图行事的信心。

如果你不能消除警告，但你可以证明引发警告的代码是类型安全的，那么（并且只能这样）用@SuppressWarnings(“unchecked”)注解来抑制警告。如果你在没有首先证明代码是类型安全的情况下压制警告，那么你给自己一个错误的安全感。代码可能会在不发出任何警告的情况下进行编译，但是它仍然可以在运行时抛出ClassCastException异常。但是，如果你忽略了你认为是安全的未经检查的警告（而不是抑制它们），那么当一个新的警告出现时，你将不会注意到这是一个真正的问题。新出现的警告就会淹没在所有的错误警告当中。

SuppressWarnings注解可用于任何声明，从单个局部变量声明到整个类。 始终在尽可能最小的范围内使用SuppressWarnings注解。通常这是一个变量声明或一个非常短的方法或构造方法。切勿在整个类上使用SuppressWarnings注解。这样做可能会掩盖重要的警告。

如果你发现自己在长度超过一行的方法或构造方法上使用SuppressWarnings注解，则可以将其移到局部变量声明上。你可能需要声明一个新的局部变量，但这是值得的。例如，考虑这个来自ArrayList的toArray方法：

public <T> T[] toArray(T[] a) {
    if (a.length < size)
       return (T[]) Arrays.copyOf(elements, size, a.getClass());
    System.arraycopy(elements, 0, a, 0, size);
    if (a.length > size)
       a[size] = null;
    return a;
}
如果编译ArrayList类，则该方法会生成此警告：
ArrayList.java:305: warning: [unchecked] unchecked cast
       return (T[]) Arrays.copyOf(elements, size, a.getClass());
                                 ^
  required: T[]
  found:    Object[]

在返回语句中设置SuppressWarnings注解是非法的，因为它不是一个声明[JLS，9.7]。你可能会试图把注释放在整个方法上，但是不要这要做。相反，声明一个局部变量来保存返回值并标注它的声明，如下所示：

// Adding local variable to reduce scope of @SuppressWarnings
public <T> T[] toArray(T[] a) {
    if (a.length < size) {
        // This cast is correct because the array we're creating
        // is of the same type as the one passed in, which is T[].
        @SuppressWarnings("unchecked") T[] result =
            (T[]) Arrays.copyOf(elements, size, a.getClass());
        return result;
    }
    System.arraycopy(elements, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

所产生的方法干净地编译，并最小化未经检查的警告被抑制的范围。

每当使用@SuppressWarnings(“unchecked”)注解时，请添加注释，说明为什么是安全的。这将有助于他人理解代码，更重要的是，这将减少有人修改代码的可能性，从而使计算不安全。如果你觉得很难写这样的注释，请继续思考。毕竟，你最终可能会发现未经检查的操作是不安全的。

总之，未经检查的警告是重要的。不要忽视他们。每个未经检查的警告代表在运行时出现ClassCastException异常的可能性。尽你所能消除这些警告。如果无法消除未经检查的警告，并且可以证明引发该警告的代码是安全类型的，则可以在尽可能小的范围内使用 @SuppressWarnings(“unchecked”)注解来禁止警告。记录你决定在注释中抑制此警告的理由。

28. 列表优于数组

数组在两个重要方面与泛型不同。首先，数组是协变的（covariant）。这个吓人的单词意味着如果Sub是Super的子类型，则数组类型Sub []是数组类型Super []的子类型。相比之下，泛型是不变的（invariant）：对于任何两种不同的类型Type1和Type2，List<Type1>既不是List <Type2>的子类型也不是父类型。[JLS，4.10; Naftalin07,2.5]。你可能认为这意味着泛型是不足的，但可以说是数组缺陷。这段代码是合法的：

// Fails at runtime!
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in"; // Throws ArrayStoreException

但这个不是：

// Won't compile!
List<Object> ol = new ArrayList<Long>(); // Incompatible types
ol.add("I don't fit in");

无论哪种方式，你不能把一个String类型放到一个Long类型容器中，但是用一个数组，你会发现在运行时产生了一个错误；对于列表，可以在编译时就能发现错误。当然，你宁愿在编译时找出错误。

数组和泛型之间的第二个主要区别是数组被具体化了（reified）[JLS，4.7]。这意味着数组在运行时知道并强制执行它们的元素类型。如前所述，如果尝试将一个String放入Long数组中，得到一个ArrayStoreException异常。相反，泛型通过擦除（erasure）来实现[JLS，4.6]。这意味着它们只在编译时执行类型约束，并在运行时丢弃（或擦除）它们的元素类型信息。擦除是允许泛型类型与不使用泛型的遗留代码自由互操作（条目 26），从而确保在Java 5中平滑过渡到泛型。

由于这些基本差异，数组和泛型不能很好地在一起混合使用。例如，创建泛型类型的数组，参数化类型的数组，以及类型参数的数组都是非法的。因此，这些数组创建表达式都不合法：new List <E> []，new List <String> []，new E []。所有将在编译时导致泛型数组创建错误。

为什么创建一个泛型数组是非法的？因为它不是类型安全的。如果这是合法的，编译器生成的强制转换程序在运行时可能会因为ClassCastException异常而失败。这将违反泛型类型系统提供的基本保证。

为了具体说明，请考虑下面的代码片段：

// Why generic array creation is illegal - won't compile!
List<String>[] stringLists = new List<String>[1];  // (1)
List<Integer> intList = List.of(42);               // (2)
Object[] objects = stringLists;                    // (3)
objects[0] = intList;                              // (4)
String s = stringLists[0].get(0);                  // (5)

让我们假设第1行创建一个泛型数组是合法的。第2行创建并初始化包含单个元素的List<Integer>。第3行将List<String>数组存储到Object数组变量中，这是合法的，因为数组是协变的。第4行将List <Integer>存储在Object数组的唯一元素中，这是因为泛型是通过擦除来实现的：List<Integer>实例的运行时类型仅仅是List，而List<String> []实例是List []，所以这个赋值不会产生ArrayStoreException异常。现在我们遇到了麻烦。将一个List<Integer>实例存储到一个声明为仅保存List<String>实例的数组中。在第5行中，我们从这个数组的唯一列表中检索唯一的元素。编译器自动将检索到的元素转换为String，但它是一个Integer，所以我们在运行时得到一个ClassCastException异常。为了防止发生这种情况，第1行（创建一个泛型数组）必须产生一个编译时错误。

类型E，List<E>和List<String>等在技术上被称为不可具体化的类型（nonreifiable types）[JLS，4.7]。直观地说，不可具体化的类型是其运行时表示包含的信息少于其编译时表示的类型。由于擦除，可唯一确定的参数化类型是无限定通配符类型，如List <?>和Map <?, ?>（条目 26）。尽管很少有用，创建无限定通配符类型的数组是合法的。

禁止泛型数组的创建可能会很恼人的。这意味着，例如，泛型集合通常不可能返回其元素类型的数组（但是参见条目 33中的部分解决方案）。这也意味着，当使用可变参数方法（条目 53）和泛型时，会产生令人困惑的警告。这是因为每次调用可变参数方法时，都会创建一个数组来保存可变参数。如果此数组的元素类型不可确定，则会收到警告。 SafeVarargs注解可以用来解决这个问题（条目 32）。

当你在强制转换为数组类型时，得到泛型数组创建错误，或是未经检查的强制转换警告时，最佳解决方案通常是使用集合类型List <E>而不是数组类型E []。这样可能会牺牲一些简洁性或性能，但作为交换，你会获得更好的类型安全性和互操作性。

例如，假设你想用带有集合的构造方法来编写一个Chooser类，并且有个方法返回随机选择的集合的一个元素。根据传递给构造方法的集合，可以使用选择器作为游戏模具，魔术8球或数据源进行蒙特卡罗模拟。这是一个没有泛型的简单实现：

// Chooser - a class badly in need of generics!
public class Chooser {
    private final Object[] choiceArray;
    public Chooser(Collection choices) {
        choiceArray = choices.toArray();
    }
    public Object choose() {
        Random rnd = ThreadLocalRandom.current();
        return choiceArray[rnd.nextInt(choiceArray.length)];
    }
}

要使用这个类，每次调用方法时，都必须将Object的choose方法的返回值转换为所需的类型，如果类型错误，则转换在运行时失败。我们先根据条目 29的建议，试图修改Chooser类，使其成为泛型的。

// A first cut at making Chooser generic - won't compile
public class Chooser<T> {
    private final T[] choiceArray;
    public Chooser(Collection<T> choices) {
        choiceArray = choices.toArray();
    }
    // choose method unchanged
}

如果你尝试编译这个类，会得到这个错误信息：

Chooser.java:9: error: incompatible types: Object[] cannot be
converted to T[]
        choiceArray = choices.toArray();
                                     ^
  where T is a type-variable:
    T extends Object declared in class Chooser

没什么大不了的，将Object数组转换为T数组：

choiceArray = (T[]) choices.toArray();

这没有了错误，而是得到一个警告：

Chooser.java:9: warning: [unchecked] unchecked cast
        choiceArray = (T[]) choices.toArray();
                                           ^
  required: T[], found: Object[]
  where T is a type-variable:
T extends Object declared in class Chooser

编译器告诉你在运行时不能保证强制转换的安全性，因为程序不会知道T代表什么类型——记住，元素类型信息在运行时会被泛型删除。该程序可以正常工作吗？是的，但编译器不能证明这一点。你可以证明这一点，在注释中提出证据，并用注解来抑制警告，但最好是消除警告的原因（条目 27）。

要消除未经检查的强制转换警告，请使用列表而不是数组。下面是另一个版本的Chooser类，编译时没有错误或警告：

// List-based Chooser - typesafe
public class Chooser<T> {
    private final List<T> choiceList;
    public Chooser(Collection<T> choices) {
        choiceList = new ArrayList<>(choices);
    }
    public T choose() {
        Random rnd = ThreadLocalRandom.current();
        return choiceList.get(rnd.nextInt(choiceList.size()));
    }
}

这个版本有些冗长，也许运行比较慢，但是值得一提的是，在运行时不会得到ClassCastException异常。

总之，数组和泛型具有非常不同的类型规则。数组是协变和具体化的; 泛型是不变的，类型擦除的。因此，数组提供运行时类型的安全性，但不提供编译时类型的安全性，反之亦然。一般来说，数组和泛型不能很好地混合工作。如果你发现把它们混合在一起，得到编译时错误或者警告，你的第一个冲动应该是用列表来替换数组。

29. 优先考虑泛型

参数化声明并使用JDK提供的泛型类型和方法通常不会太困难。但编写自己的泛型类型有点困难，但值得努力学习。

考虑条目 7中的简单堆栈实现：

// Object-based collection - a prime candidate for generics
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }
    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null; // Eliminate obsolete reference
        return result;
    }
    public boolean isEmpty() {
        return size == 0;
    }
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

这个类应该已经被参数化了，但是由于事实并非如此，我们可以对它进行泛型化。换句话说，我们可以参数化它，而不会损害原始非参数化版本的客户端。就目前而言，客户端必须强制转换从堆栈中弹出的对象，而这些强制转换可能会在运行时失败。泛型化类的第一步是在其声明中添加一个或多个类型参数。在这种情况下，有一个类型参数，表示堆栈的元素类型，这个类型参数的常规名称是E（条目 68）。

下一步是用相应的类型参数替换所有使用的Object类型，然后尝试编译生成的程序：

// Initial attempt to generify Stack - won't compile!
public class Stack<E> {
    private E[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    public Stack() {
        elements = new E[DEFAULT_INITIAL_CAPACITY];
    }
    public void push(E e) {
        ensureCapacity();
        elements[size++] = e;
    }
    public E pop() {
        if (size == 0)
            throw new EmptyStackException();
        E result = elements[--size];
        elements[size] = null; // Eliminate obsolete reference
        return result;
    }
    ... // no changes in isEmpty or ensureCapacity
}

你通常会得到至少一个错误或警告，这个类也不例外。幸运的是，这个类只产生一个错误：

Stack.java:8: generic array creation
        elements = new E[DEFAULT_INITIAL_CAPACITY];
                   ^

如条目 28所述，你不能创建一个不可具体化类型的数组，例如类型E。每当编写一个由数组支持的泛型时，就会出现此问题。有两种合理的方法来解决它。第一种解决方案直接规避了对泛型数组创建的禁用：创建一个Object数组并将其转换为泛型数组类型。现在没有了错误，编译器会发出警告。这种用法是合法的，但不是（一般）类型安全的：

Stack.java:8: warning: [unchecked] unchecked cast
found: Object[], required: E[]
        elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
                       ^

编译器可能无法证明你的程序是类型安全的，但你可以。你必须说服自己，不加限制的类型强制转换不会损害程序的类型安全。有问题的数组（元素）保存在一个私有属性中，永远不会返回给客户端或传递给任何其他方法。保存在数组中的唯一元素是那些传递给push方法的元素，它们是E类型的，所以未经检查的强制转换不会造成任何伤害。

一旦证明未经检查的强制转换是安全的，请尽可能缩小范围（条目 27）。在这种情况下，构造方法只包含未经检查的数组创建，所以在整个构造方法中抑制警告是合适的。通过添加一个注解来执行此操作，Stack可以干净地编译，并且可以在没有显式强制转换或担心ClassCastException异常的情况下使用它：

// The elements array will contain only E instances from push(E).
// This is sufficient to ensure type safety, but the runtime
// type of the array won't be E[]; it will always be Object[]!
@SuppressWarnings("unchecked")
public Stack() {
    elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
}

消除Stack中的泛型数组创建错误的第二种方法是将属性元素的类型从E []更改为Object []。如果这样做，会得到一个不同的错误：

Stack.java:19: incompatible types
found: Object, required: E
        E result = elements[--size];
                           ^

可以通过将从数组中检索到的元素转换为E来将此错误更改为警告：

Stack.java:19: warning: [unchecked] unchecked cast
found: Object, required: E
        E result = (E) elements[--size];
                               ^

因为E是不可具体化的类型，编译器无法在运行时检查强制转换。再一次，你可以很容易地向自己证明，不加限制的转换是安全的，所以可以适当地抑制警告。根据条目 27的建议，我们只在包含未经检查的强制转换的分配上抑制警告，而不是在整个pop方法上：

// Appropriate suppression of unchecked warning
public E pop() {
    if (size == 0)
        throw new EmptyStackException();
    // push requires elements to be of type E, so cast is correct
    @SuppressWarnings("unchecked") E result =
        (E) elements[--size];
    elements[size] = null; // Eliminate obsolete reference
    return result;
}

两种消除泛型数组创建的技术都有其追随者。第一个更可读：数组被声明为E []类型，清楚地表明它只包含E实例。它也更简洁：在一个典型的泛型类中，你从代码中的许多点读取数组; 第一种技术只需要一次转换（创建数组的地方），而第二种技术每次读取数组元素都需要单独转换。因此，第一种技术是优选的并且在实践中更常用。但是，它确实会造成堆污染（heap pollution）（条目 32）：数组的运行时类型与编译时类型不匹配（除非E碰巧是Object）。这使得一些程序员非常不安，他们选择了第二种技术，尽管在这种情况下堆的污染是无害的。

下面的程序演示了泛型Stack类的使用。该程序以相反的顺序打印其命令行参数，并将其转换为大写。对从堆栈弹出的元素调用String的toUpperCase方法不需要显式强制转换，而自动生成的强制转换将保证成功：

// Little program to exercise our generic Stack
public static void main(String[] args) {
    Stack<String> stack = new Stack<>();
    for (String arg : args)
        stack.push(arg);
    while (!stack.isEmpty())
        System.out.println(stack.pop().toUpperCase());
}

上面的例子似乎与条目 28相矛盾，条目 28中鼓励使用列表优先于数组。在泛型类型中使用列表并不总是可行或可取的。 Java本身生来并不支持列表，所以一些泛型类型（如ArrayList）必须在数组上实现。其他的泛型类型，比如HashMap，是为了提高性能而实现的。

绝大多数泛型类型就像我们的Stack示例一样，它们的类型参数没有限制：可以创建一个Stack <Object>，Stack <int []>，Stack <List <String >>或者其他任何对象的Stack引用类型。请注意，不能创建基本类型的堆栈：尝试创建Stack<int>或Stack<double>将导致编译时错误。这是Java泛型类型系统的一个基本限制。可以使用基本类型的包装类（条目 61）来解决这个限制。

有一些泛型类型限制了它们类型参数的允许值。例如，考虑java.util.concurrent.DelayQueue，它的声明如下所示：

class DelayQueue<E extends Delayed> implements BlockingQueue<E>

类型参数列表（<E extends Delayed>）要求实际的类型参数E是java.util.concurrent.Delayed的子类型。这使得DelayQueue实现及其客户端可以利用DelayQueue元素上的Delayed方法，而不需要显式的转换或ClassCastException异常的风险。类型参数E被称为限定类型参数。请注意，子类型关系被定义为每个类型都是自己的子类型[JLS，4.10]，因此创建DelayQueue <Delayed>是合法的。

总之，泛型类型比需要在客户端代码中强制转换的类型更安全，更易于使用。当你设计新的类型时，确保它们可以在没有这种强制转换的情况下使用。这通常意味着使类型泛型化。如果你有任何现有的类型，应该是泛型的但实际上却不是，那么把它们泛型化。这使这些类型的新用户的使用更容易，而不会破坏现有的客户端（条目 26）。

参考文章：www.jianshu.com/p/8bc1615c7…

Effective Java 第五章泛型(1)

26. 不要使用原始类型

27. 消除非检查警告

28. 列表优于数组

29. 优先考虑泛型

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Effective Java 第五章 泛型(1)

26. 不要使用原始类型

27. 消除非检查警告

28. 列表优于数组

29. 优先考虑泛型

热门文章

最新文章

相关课程

相关电子书

相关实验场景

Effective Java 第五章泛型(1)