一. 泛型概念的提出（為什麼需要泛型）？
首先，我們看下下面這段簡短的代碼:
定義了一個List類型的集合，先向其中加入了兩個字元串類型的值，随後加入一個Integer類型的值。這是完全允許的，因為此時list預設的類型為Object類型。在之後的循環中，由于忘記了之前在list中也加入了Integer類型的值或其他編碼原因，很容易出現類似于//1中的錯誤。因為編譯階段正常，而運作時會出現“java.lang.ClassCastException”異常。是以，導緻此類錯誤編碼過程中不易發現。
在如上的編碼過程中，我們發現主要存在兩個問題：
1.當我們将一個對象放入集合中，集合不會記住此對象的類型，當再次從集合中取出此對象時，改對象的編譯類型變成了Object類型，但其運作時類型任然為其本身類型。
2.是以，//1處取出集合元素時需要人為的強制類型轉化到具體的目标類型，且很容易出現“java.lang.ClassCastException”異常。
那麼有沒有什麼辦法可以使集合能夠記住集合内元素各類型，且能夠達到隻要編譯時不出現問題，運作時就不會出現“java.lang.ClassCastException”異常呢？答案就是使用泛型。
二.什麼是泛型？
泛型，即“參數化類型”。一提到參數，最熟悉的就是定義方法時有形參，然後調用此方法時傳遞實參。那麼參數化類型怎麼了解呢？顧名思義，就是将類型由原來的具體的類型參數化，類似于方法中的變量參數，此時類型也定義成參數形式（可以稱之為類型形參），然後在使用/調用時傳入具體的類型（類型實參）。
看着好像有點複雜，首先我們看下上面那個例子采用泛型的寫法。
采用泛型寫法後，在//1處想加入一個Integer類型的對象時會出現編譯錯誤，通過List<String>，直接限定了list集合中隻能含有String類型的元素，進而在//2處無須進行強制類型轉換，因為此時，集合能夠記住元素的類型資訊，編譯器已經能夠确認它是String類型了。
結合上面的泛型定義，我們知道在List<String>中，String是類型實參，也就是說，相應的List接口中肯定含有類型形參。且get()方法的傳回結果也直接是此形參類型（也就是對應的傳入的類型實參）。下面就來看看List接口的的具體定義：
我們可以看到，在List接口中采用泛型化定義之後，<E>中的E表示類型形參，可以接收具體的類型實參，并且此接口定義中，凡是出現E的地方均表示相同的接受自外部的類型實參。
自然的，ArrayList作為List接口的實作類，其定義形式是：
由此，我們從源代碼角度明白了為什麼//1處加入Integer類型對象編譯錯誤，且//2處get()到的類型直接就是String類型了。
三.自定義泛型接口、泛型類和泛型方法
從上面的内容中，大家已經明白了泛型的具體運作過程。也知道了接口、類和方法也都可以使用泛型去定義，以及相應的使用。是的，在具體使用時，可以分為泛型接口、泛型類和泛型方法。
自定義泛型接口、泛型類和泛型方法與上述Java源碼中的List、ArrayList類似。如下，我們看一個最簡單的泛型類和方法定義：
在泛型接口、泛型類和泛型方法的定義過程中，我們常見的如T、E、K、V等形式的參數常用于表示泛型形參，由于接收來自外部使用時候傳入的類型實參。那麼對于不同傳入的類型實參，生成的相應對象執行個體的類型是不是一樣的呢？
由此，我們發現，在使用泛型類時，雖然傳入了不同的泛型實參，但并沒有真正意義上生成不同的類型，傳入不同泛型實參的泛型類在記憶體上隻有一個，即還是原來的最基本的類型（本執行個體中為Box），當然，在邏輯上我們可以了解成多個不同的泛型類型。
究其原因，在于Java中的泛型這一概念提出的目的，導緻其隻是作用于代碼編譯階段，在編譯過程中，對于正确檢驗泛型結果後，會将泛型的相關資訊擦出，也就是說，成功編譯過後的class檔案中是不包含任何泛型資訊的。泛型資訊不會進入到運作時階段。
對此總結成一句話：泛型類型在邏輯上看以看成是多個不同的類型，實際上都是相同的基本類型。
四.類型通配符
接着上面的結論，我們知道，Box<Number>和Box<Integer>實際上都是Box類型，現在需要繼續探讨一個問題，那麼在邏輯上，類似于Box<Number>和Box<Integer>是否可以看成具有父子關系的泛型類型呢？
為了弄清這個問題，我們繼續看下下面這個例子:
我們發現，在代碼//1處出現了錯誤提示資訊：The method getData(Box<Number>) in the t ype GenericTest is not applicable for the arguments (Box<Integer>)。顯然，通過提示資訊，我們知道Box<Number>在邏輯上不能視為Box<Integer>的父類。那麼，原因何在呢？
這個例子中，顯然//1和//2處肯定會出現錯誤提示的。在此我們可以使用反證法來進行說明。
假設Box<Number>在邏輯上可以視為Box<Integer>的父類，那麼//1和//2處将不會有錯誤提示了，那麼問題就出來了，通過getData()方法取出資料時到底是什麼類型呢？Integer? Float? 還是Number？且由于在程式設計過程中的順序不可控性，導緻在必要的時候必須要進行類型判斷，且進行強制類型轉換。顯然，這與泛型的理念沖突，是以，在邏輯上Box<Number>不能視為Box<Integer>的父類。
好，那我們回過頭來繼續看“類型通配符”中的第一個例子，我們知道其具體的錯誤提示的深層次原因了。那麼如何解決呢？總部能再定義一個新的函數吧。這和Java中的多态理念顯然是違背的，是以，我們需要一個在邏輯上可以用來表示同時是Box<Integer>和Box<Number>的父類的一個引用類型，由此，類型通配符應運而生。
類型通配符一般是使用 ? 代替具體的類型實參。注意了，此處是類型實參，而不是類型形參！且Box<?>在邏輯上是Box<Integer>、Box<Number>...等所有Box<具體類型實參>的父類。由此，我們依然可以定義泛型方法，來完成此類需求。
有時候，我們還可能聽到類型通配符上限和類型通配符下限。具體有是怎麼樣的呢？
在上面的例子中，如果需要定義一個功能類似于getData()的方法，但對類型實參又有進一步的限制：隻能是Number類及其子類。此時，需要用到類型通配符上限。
此時，顯然，在代碼//1處調用将出現錯誤提示，而//2 //3處調用正常。
類型通配符上限通過形如Box<? extends Number>形式定義，相對應的，類型通配符下限為Box<? super Number>形式，其含義與類型通配符上限正好相反，在此不作過多闡述了。
五.話外篇
本文中的例子主要是為了闡述泛型中的一些思想而簡單舉出的，并不一定有着實際的可用性。另外，一提到泛型，相信大家用到最多的就是在集合中，其實，在實際的程式設計過程中，自己可以使用泛型去簡化開發，且能很好的保證代碼品質。并且還要注意的一點是，Java中沒有所謂的泛型數組一說。
對于泛型，最主要的還是需要了解其背後的思想和目的。
本文轉自左正部落格園部落格，原文連結：http://www.cnblogs.com/soundcode/p/6295906.html，如需轉載請自行聯系原作者