????????首先介紹一些術(shù)語(yǔ) 。 聲明中具有一個(gè)或者多個(gè)類型參數(shù)（ type parameter ）的類或者接口，就是泛型（ generic ）類或者接口?。 例如，List 接口就只有單個(gè)類型參數(shù) E ，表示列表的元素類型 。這個(gè)接口的全稱是 List<E> （讀作“ E 的列表”），但是人們經(jīng)常把它簡(jiǎn)稱為 List 。 泛型類和接口統(tǒng)稱為泛型（ generic type ） 。

????????每一種泛型定義一組參數(shù)化的類型（ parameterized type)，構(gòu)成格式為 ： 先是類或者接口的名稱，接著用尖括 號(hào)（＜＞） 把對(duì)應(yīng)于泛型形式類型參數(shù)的實(shí)際類型參數(shù)列表括起來(lái) 。 例如，List< String> （讀作 “字符串列表”）是一個(gè)參數(shù)化的類型，表示元素類型為 String 的列表 。（String 是與形式的類型參數(shù) E 相對(duì)應(yīng)的實(shí)際類型參數(shù) 。）

????????最后一點(diǎn)，每一種泛型都定義一個(gè)原生態(tài)類型（ raw type ），即不帶任何實(shí)際類型參數(shù)的泛型名稱 。 例如，與 List < E＞相對(duì)應(yīng)的原生態(tài)類型是 List 。 原生態(tài)類型就像從類型聲明中刪除了所有泛型信息一樣 。 它們的存在主要是為了與泛型出現(xiàn)之前的代碼相兼容 。

????????在 Java 增加泛型之前，下面這個(gè)集合聲明是值得參考的 。 從 Java 9 開(kāi)始，它依然合法，但是已經(jīng)沒(méi)什么參考價(jià)值了：

private final Collection stamps = ...;

????????如果現(xiàn)在使用這條聲明，并且不小心將一個(gè) coin 放進(jìn)了 stamp 集合中，這一錯(cuò)誤的插入照樣得以編譯和運(yùn)行，不會(huì)出錯(cuò)（不過(guò)編譯器確實(shí)會(huì)發(fā)出一條模糊 的警告信息） ：

stamps.add(new Coin( ... ));

直到從 stamp 集合中獲取 co 工 n 時(shí)才會(huì)收到一條錯(cuò)誤提示：

for (Iterator i = stamps.iterator(); i.hasNext(); )Stamp stamp = (Stamp) i.next(); stamp.cancel() ;

????????出錯(cuò)之后應(yīng)該盡快發(fā)現(xiàn)， 最好是編譯時(shí)就發(fā)現(xiàn)。在本例中，直到運(yùn)行時(shí)才發(fā)現(xiàn)錯(cuò)誤，已經(jīng)出錯(cuò)很久了，而且它在代碼中所處的位置，距離包含錯(cuò)誤的這部分代碼已經(jīng)很遠(yuǎn)了 。一旦發(fā)現(xiàn)ClassCastException ，就必須搜索代碼，查找將coin 放進(jìn) stamp 集合的方法調(diào)用 。 此時(shí)編譯器幫不上忙，因?yàn)樗鼰o(wú)法理解這種注釋 ：“ Contains only Stamp instances ”（只包含 Stamp 實(shí)例）。

有了泛型之后，類型聲 明中可以包含以下信息，而不是注釋 ：

private final Collection<Stamp> stamps = ...;

????????通過(guò)這條聲明，編譯器知道 stamps 應(yīng)該只包含 Stamp 實(shí)例，并給予保證（ guarantee），假設(shè)整個(gè)代碼庫(kù)在編譯過(guò)程中都沒(méi)有發(fā)出任何警告 。當(dāng) stamps利用一個(gè)參數(shù)化的類型進(jìn)行聲明時(shí)，錯(cuò)誤的插入會(huì)產(chǎn)生一條編譯時(shí)的錯(cuò)誤消息，告訴你具體是哪里出錯(cuò)了。

????????從集合中檢索元素時(shí)，編譯器會(huì)替你插入隱式的轉(zhuǎn)換，并確保它們不會(huì)失敗（依然假設(shè)所有代碼都沒(méi)有產(chǎn)生或者隱瞞任何編譯警告） 。 假設(shè)不小心將 coin 插入 stamp 集合，這顯得有點(diǎn)牽強(qiáng)，但這類問(wèn)題卻是真實(shí)的 。 例如，很容易想象有人會(huì)不小心將一個(gè)Biginteger 實(shí)例放進(jìn)一個(gè)原本只包含 BigDecimal 實(shí)例的集合中 。

????????如上所述，使用原生態(tài)類型（沒(méi)有類型參數(shù)的泛型）是合法的，但是永遠(yuǎn)不應(yīng)該這么做 。 如果使用原生態(tài)類型，就失掉了泛型在安全性和描述性方面的所有優(yōu)勢(shì) 。 既然不應(yīng)該使用原生態(tài)類型 ，為什么 Java 語(yǔ)言的設(shè)計(jì)者還要允許使用它們呢？這是為了提供兼容性 。

????????因?yàn)榉盒统霈F(xiàn)的時(shí)候，Java 平臺(tái)即將進(jìn)入它的第二個(gè)十年，已經(jīng)存在大量沒(méi)有使用泛型的Java 代碼 。 人們認(rèn)為讓所有這些代碼保持合法，并且能夠與使用泛型的新代碼互用，這一點(diǎn)很重要。它必須合法才能將參數(shù)化類型的實(shí)例傳遞給那些被設(shè)計(jì)成使用普通類型的方法，反之亦然 。 這種需求被稱作移植兼容性（ Migration Compatibility ），促成了支持原生態(tài)類型，以及利用擦除（ erasure) 實(shí)現(xiàn)泛型的決定 。

????????雖然不應(yīng)該在新代碼中使用像 List 這樣的原生態(tài)類型，使用參數(shù)化的類型以允許插入任意對(duì)象（比如 List<Object ＞）是可行的 。 原生態(tài)類型 List 和參數(shù)化的類型 List<Object>之間到底有什么區(qū)別呢？不嚴(yán)格地說(shuō)，前者逃避了泛型檢查，后者則明確告知編譯器，它能夠持有任意類型的對(duì)象。 雖然可以將 List<String>?傳遞給類型 List 的參數(shù)，但是不能將它傳給類型 List<Object>的參數(shù)。 泛型有子類型化（ subtyping ）的規(guī)則，List<String>是原生態(tài)類型 List 的一個(gè)子類型，而不是參數(shù)化類型 List<Object>的子類型 。因此， 如果使用像 List 這樣的原生態(tài)類型，就會(huì)失掉類型安全性 ， 但是如果使用像 List<Object ＞這樣的參數(shù)化類型，則不會(huì) 。

????????為了更具體地進(jìn)行說(shuō)明，請(qǐng)參考下面的程序：

public static void main(String[] args) {List<String> strings = new ArrayList<>();unsafeAdd(strings, Integer.value0f(42));String s = strings.get(0); // Has compiler-generated castprivate static void unsafeAdd(List list, object o) {list.add(o);
}

????????這段程序可以進(jìn)行編譯，但是因?yàn)樗褂昧嗽鷳B(tài)類型 List ，你會(huì)收到一條警告：

????????實(shí)際上，如果運(yùn)行這段程序，在程序試圖將 strings.get(o）的調(diào)用結(jié)果 Integer轉(zhuǎn)換成 String時(shí)，你會(huì)收到一個(gè) ClassCastException 異常 。 這是一個(gè)編譯器生成的轉(zhuǎn)換，因此一般保證會(huì)成功，但是我們?cè)谶@個(gè)例子中忽略了一條編譯器警告，為此付出了代價(jià) 。如果在 unsafeAdd 聲明中用參數(shù)化類型 List<Object＞代替原生態(tài)類型 List ，并試著重新編譯這段程序，會(huì)發(fā)現(xiàn)它無(wú)法再進(jìn)行編譯了，并發(fā)出以下錯(cuò)誤消息：

????????在不確定或者不在乎集合中的元素類型的情況下，你也許會(huì)使用原生態(tài)類型 。 例如，假設(shè)想要編寫一個(gè)方法，它有兩個(gè)集合，并從中返回它們共有元素的數(shù)量 。 如果你對(duì)泛型還不熟悉，可以參考以下方式來(lái)編寫這種方法：

static int numElementsInCommon(Set s1, Set s2) {int result = 0;for (Object o1 : s1)if (s2.contains(o1))result++;return result;
}

????????這個(gè)方法可行，但它使用了原生態(tài)類型，這是很危險(xiǎn)的 。 安全的替代做法是使用無(wú)限制的通配符類型（ unbounded wildcard type ） 。 如果要使用泛型，但不確定或者不關(guān)心實(shí)際的類型參數(shù)，就可以用一個(gè)問(wèn)號(hào)代替 。 例如，泛型 Set<E＞的無(wú)限制通配符類型為 Set <?>（讀作“某個(gè)類型的集合”） 。 這是最普通的參數(shù)化 S et 類型，可 以持有任何集合 。 下面是numElementsinCommon 方法使用了無(wú)限制通配符類型時(shí)的情形 ：

static int numElementsInCommon(Set<?> s1， Set<?> s2) {...}

????????無(wú)限制通配類型 Set ＜＞和原生態(tài)類型 Set 之間有什么區(qū)別呢？這個(gè)問(wèn)號(hào)真正起到作用了嗎？這一點(diǎn)不需要贅述，但通配符類型是安全的，原生態(tài)類型則不安全 。 由于可以將任何元素放進(jìn)使用原生態(tài)類型的集合中，因此很容易破壞該集合的類型約束條件（如之前范例中所示的 unsafeAdd 方法）；但不能將任何元素（除了 null 之 外）放到 Collection < ?>中 。 如果嘗試這么做，將會(huì)產(chǎn)生一條像這樣的編譯時(shí)錯(cuò)誤消息：

????????這樣的錯(cuò)誤消息顯然無(wú)法令人滿意，但是編譯器已經(jīng)盡到了它的職責(zé)，防止你破壞集合的類型約束條件 。 你不僅無(wú)法將任何元素（除了 null 之外）放進(jìn) Collection ＜？＞ 中，而且根本無(wú)法猜測(cè)你會(huì)得到哪種類型的對(duì)象 。 要是無(wú)法接受這些限制，就可以使用泛型方法或者有限制的通配符類型 。

????????不要使用原生態(tài)類型，這條規(guī)則有幾個(gè)小小的例外 。 必須在類文字中 使用原生態(tài)類型 。 規(guī)范不允許使用參數(shù)化類型（雖然允許數(shù)組類型和基本類型）。換句話說(shuō)， List.class 、 String[].class 和 int.class 都合法，但是 List<String.class 和 List<?>.class 則不合法 。

????????這條規(guī)則的第二個(gè)例外與 ins ta口 ceof 操作符有關(guān) 。 由于泛型信息可以在運(yùn)行時(shí)被擦除，因此在參數(shù)化類型而非無(wú)限制通配柯：類型上使用 instanceof 操作符是非法的 。 用無(wú)限制通配符類型代替原生態(tài)類型，對(duì) instanceof 操作符的行為不會(huì)產(chǎn)生任何影響 。 在這種情況下，尖括號(hào)（ ＜＞）和問(wèn)號(hào)（？）就顯得多余了 。 下面是利用泛型來(lái)使用 instanceof操作符的首選方法 ：

if (o instanceof Set) {Set<?> s = (Set<?>) o;
}

????????注意，一旦確定這個(gè) o 是個(gè) Set ，就必須將它轉(zhuǎn)換成通配符類型 Set ＜？＞，而不是轉(zhuǎn)換成原生態(tài)類型 Set 。 這是個(gè)受檢的（ checked ）轉(zhuǎn)換，因此不會(huì)導(dǎo)致編譯時(shí)警告 。

????????總而言之，使用原生態(tài)類型會(huì)在運(yùn)行時(shí)導(dǎo)致異常，因此不要使用 。 原生態(tài)類型只是為了與引人泛型之前的遺留代碼進(jìn)行兼容和互用而提供的 。 讓我們做個(gè)快速的回顧：Set<Object ＞是個(gè)參數(shù)化類型，表示可以包含任何對(duì)象類型的一個(gè)集合；Set ＜？＞則是一個(gè)通配符類型，表示只能包含某種未知對(duì)象類型的一個(gè)集合；Set 是一個(gè)原生態(tài)類型，它脫離了泛型系統(tǒng) 。 前兩種是安全的，最后一種不安全。