本文主要介紹泛型誕生的前世今生，特性，以及著名PECS原則的由來。

在日常開發中，必不可少的會使用到泛型，這個過程中經常會出現類似“為什么這樣會編譯報錯？”，“為什么這個列表無法添加元素？”的問題，也會出現感嘆Java的泛型限制太多了很難用的情況。

為了更好的使用泛型，就需要更深地了解它，因此本文主要介紹泛型誕生的前世今生，特性，以及著名PECS原則的由來。

泛型的誕生

背景

在沒有泛型之前，必須使用Object編寫適用于多種類型的代碼，想想就令人頭疼，并且非常的不安全。同時由于數組的存在，設計者為了讓其可以比較通用的進行處理，也讓數組允許協變，這又為程序添加了一些天然的不安全因素。為了解決這些情況，Java的設計者終于在Java5中引入泛型，然而，正是因為引入泛型的時機較晚，為了兼容先前的代碼，設計者也不得不做出一些限制，來讓使用者（也就是我們）以難受換來一些安全。

優點

簡單來說，泛型的引入有以下好處：

程序更加易讀

安全性有所保證

以ArrayList舉例，在增加泛型類之前，其通用性是用繼承來實現的，ArrayList類只維護一個Object引用的數組，當我們使用這個工具類時，想要獲取指定類型的對象必須經過強轉：

import java.util.ArrayList;
import java.util.Date;

public class Main {
  public static void main(String[] args) {
    ArrayList list = new ArrayList();
    //強制類型轉換
    String res = (String) list.get(0);
    //十分不安全的行為
    list.add(new Date());
  }
}

這種寫法在編譯類型時不會報錯，但一旦使用get獲取結果并試圖將Date轉換為其他類型時，很有可能出現類型轉換異常，為了解決這種情況，類型參數應用而生。

類型參數

類型參數（Type parameter）使得ArrayList以及其他可能用到的集合類能夠方便的指示虛擬機其包含元素的類型:?

import java.util.ArrayList;


public class Main {
  public static void main(String[] args) {
    ArrayList objects = new ArrayList<>();
    objects.add("Hello");
  }
}

這使得代碼具有更好的可讀性，并且在調用get()的時候，無需進行強轉，最重要的是，編譯器終于可以檢查一個插入操作是否符合要求，運行時可能出現的各種類型轉換錯誤得以在編譯階段就被阻止。

import java.util.ArrayList;
import java.util.Date;


public class Main {
  public static void main(String[] args) {
    ArrayList objects = new ArrayList<>();
    //we can do it like that
    objects.add("Hello");
    //wrong example
    objects.add(new Date());
  }
}

基本用法

一般來說，使用泛型工具類很容易，但是自己編寫會相對困難很多，設計者必須考慮的相當周全才能使自己的泛型類庫比較完善。

泛型類

泛型類是有一個或者多個類型變量的類，泛型類中的屬性可以全都不是泛型，不過一般不會這樣做，畢竟類型變量在整個類上定義就是用于指定方法的返回類型以及字段的類型，定義代碼如下：?

public class Animal {
  private String name;
  private T mouth;
  
  public T getMouth(){
    return mouth;
  }
}

泛型類可以有多個類型變量：

public class Animal {
  private String name;
  private T mouth;
  private U eyes;


  public T getMouth(){
    return mouth;
  }
}

泛型方法

泛型方法可以在普通類中定義，也可以在泛型類中定義，例如：

public class Animal {
  private T value;
  public static  T get(T... a){
    return a[a.length-1];
  }
  public T getFirst(){
    return value;
  }
}

類型擦除

虛擬機沒有泛型類型對象，也就是說，所有對象在虛擬機中都屬于普通類，這意味著在程序編譯并運行后我們的類型變量會被擦除（erased）并替換為限定類型，擦掉類型參數后的類型就叫做原始類型（raw type），正是因為有類型參數，所以下面的比較結果會為true:

?

這里的替換規則我個人理解為：“替換最近上界”，也就是無限定符修飾，則為頂級父類Object，如果有，則會替換為其指定的類型。最直觀的示例如下，這就是類型擦除的體現：

?

??

前面說過，泛型是在1.5才提出的，因此類型擦除的目的就是為了保證已有的代碼和類文件依然合法，也就是向低版本兼容。這樣做會帶來幾個問題：

1.類型參數不支持基本類型，只支持引用類型，這是因為泛型會被擦除為具體類型，而Object不能存儲基本類型的值。

運行時你只能對原始類型進行類型檢測：

?

2.不能實例化類型參數

不能實例化泛型數組，因為類型擦除會將數組變為Object數組，如果允許實例化，極易造成類型轉換異常。

強制轉換

在編寫泛型方法調用時，如果擦出了返回類型，編譯器會插入強制類型轉換。例如下面的代碼：

public class Main {
  public static void main(String[] args) {
    Animal pair = new Animal<>();
    Integer first = pair.getFirst();
  }
}

getFirst擦除類型后的返回類型是Object，編譯器自動插入轉換到Integer的強制類型轉換，也就是說，編譯器把這個方法調用轉換為兩條虛擬機指令：

對原始方法的調用。

將返回的Object類型強制轉換為Integer類型。

方法橋接

子類重寫父類方法時，必須和父類保持相同的方法名稱，參數列表和返回類型。那么問題來了，如果按照之前的思路來講，當泛型父類或接口的類型參數被擦除了，那么子類豈不是不構成重寫條件？（參數類型很可能變化）：

擦除前：

?

擦除后：

?

為了解決這個事情，Java引入了橋接方法，為每個繼承/實現泛型類/接口的子類服務，以此保持多態性，字節碼如下：

?

(圖片來源：RudeCrab)

其實現原理，就是重寫擦除后的父類方法，并在其內部委托了原始的子類方法，巧妙繞過了擦除帶來的影響。不僅如此，就算不是泛型類，當子類方法重寫父類方法的返回類型是父類返回類型的子類時，編譯器也會生成橋接方法來滿足重寫的規則。

總結

Java核心技術中總結的非常到位：

虛擬機中沒有泛型，只有普通的類和方法。

所有的類型參數都會替換為他們的限定類型。

會合成橋接方法來保持多態。

為保持類型安全性，必要時會插入強制類型轉換。

變型（Variant）與數組

變型是類型系統中很重要的概念，主要有三個規則協變，逆變，和不變：

?

這三個類型可以解釋為：假設有一個類型構造器f，它可以將已知類型轉換為另一種類型，那么，有Animal父類和Dog子類。

則f(Dog)是f(Animal)的子類，稱為協變；

則f(Dog)是f(Animal)的父類，成為逆變；

則f(Dog)和f(Animal)沒有任何關系；

而這個f()，可以是泛型，可以是數組，也可以是方法。

知道了以上概念，我們需要直接指出，泛型默認是不支持協變的，原因很簡單，類型安全：如果允許協變，可能會造成類型轉換異常。而數組支持協變，正如文章開頭所說，就是設計者希望可以對數組進行比較通用的處理，防止方法為每一種類型編寫重復邏輯，這樣做也確實導致為數組賦值元素時可能會拋出運行時異常ArrayStoreException，這是一個很危險的坑。Effective Java中直接指出允許數組協變是Java的缺陷，我想這也是要多用列表而不用數組的原因之一。

泛型協變—PECS原則

為了讓泛型也支持多態，讓其支持協變是很必要的，最常用的場景：我們想讓一個方法接受一個集合，并做統一的邏輯處理，如果泛型不支持協變，這種很基本的需求都會成為奢望。

上界

讓泛型支持協變很簡單，只需要使用? extends的組合即可實現，?稱為通配符，這種組合方式聲明了類型的上界，標識泛型可接受的類型只能是指定類型或是其子類。在這里，ElectricVehicle和Diesel均是繼承自Car。

?

為了杜絕可協變后出現類似于數組一樣的安全隱患，泛型設計采用了“一刀切”的方式，即：只要聲明了上界，除了null之外，一律不準傳入給泛型。說白了，就是只讀不寫，這樣當然可以保證安全性。

?

到這里可以順便說一下集合的設計，可以注意到集合中只有add方法是泛型參數，而其余方法并不是，為何要這樣設計，為何不把其余方法的參數類型也改為E？其原因就是在于，如果將contains和remove改為E，那么聲明上界之后，調用這兩個方法會引發編譯錯誤，然而這兩個方法均為類型安全方法，自然不可聲明為E，add作為很明顯的寫方法，自然也需要用E作為參數類型，到這里，不得不感嘆類庫設計者的想法獨到。

?

下界

對應協變的上界，自然有逆變的下界，很自然的，我們使用? super的組合來聲明一個泛型的下界，來表示可以接收本類型或者其父類型。

?

而且相對應的，正是由于最多只能接收父類型泛型，所以不會有類型轉換失敗的風險，因此逆變可以添加元素，不過添加的元素類型只能是指定類型和其子類，切記不要把添加元素和接收泛型類參數給弄混了。

有利有弊，雖然逆變沒有了協變只讀不寫的限制，但是讀取元素時將不能確定具體的類型，只能用Object來接收：

?

PECS

正如上面對上下界的描述，我們已經明白了大致的應用場景，當我們需要只讀不寫時，就用協變，只寫不讀，就用逆變。又想讀又想寫，我們應該指明準確的泛型類型。

注明的PECS原則就總結了這一點，PECS（Prodcuer extends Consumer super），也就是說，作為元素的生產者Prodcuer，要用協變，支持元素的讀取，而作為消費者Consumer，要支持逆變，支持元素的寫入。

?

Collections的copy方法就非常好的印證了這一點：