引出泛型
我們通過如下的示例,引出為什么泛型的概念。
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class test { public static void main(string[] args) { list list = new arraylist(); list.add( "abc" ); list.add( 2 ); for ( int i = 0 ; i < list.size(); i++) { string name = (string) list.get(i); // error system.out.println( "name:" + name); } } } |
當獲取列表中的第二個元素時,會報錯,java.lang.classcastexception: java.lang.integer cannot be cast to java.lang.string。這是常見的類型轉換錯誤。
當我們將元素放入到列表中,并沒有使用指定的類型,在取出元素時使用的是默認的 object 類型。因此很容易出現類型轉換的異常。
我們想要實現的結果是,集合能夠記住集合內元素各類型,且能夠達到只要編譯時不出現問題,運行時就不會出現 java.lang.classcastexception 異常。泛型剛好能滿足我們的需求。
什么是泛型?
泛型,即參數化類型。一提到參數,最熟悉的就是定義方法時有形參,然后調用此方法時傳遞實參。那么參數化類型怎么理解呢?顧名思義,就是將類型由原來的具體的類型參數化,類似于方法中的變量參數,此時類型也定義成參數形式(可以稱之為類型形參),然后在使用/調用時傳入具體的類型(類型實參)。
泛型的本質是為了參數化類型,即在不創建新的類型的情況下,通過泛型指定的不同類型來控制形參具體限制的類型。在泛型使用過程中,操作的數據類型被指定為一個參數,這種參數類型可以用在類、接口和方法中,分別被稱為泛型類、泛型接口和泛型方法。
泛型的特點
java 語言中引入泛型是一個較大的功能增強。不僅語言、類型系統和編譯器有了較大的變化,已支持泛型,而且類庫也進行了大翻修,所以許多重要的類,比如集合框架,都已經成為泛型化的了。這帶來了很多好處:
- 類型安全。 泛型的主要目標是提高 java 程序的類型安全。通過知道使用泛型定義的變量的類型限制,編譯器可以在一個高得多的程度上驗證類型假設。
- 消除強制類型轉換。 泛型的一個附帶好處是,消除源代碼中的許多強制類型轉換。這使得代碼更加可讀,并且減少了出錯機會。
- 潛在的性能收益。 泛型為較大的優化帶來可能。在泛型的初始實現中,編譯器將強制類型轉換(沒有泛型的話,程序員會指定這些強制類型轉換)插入生成的字節碼中。
命名類型參數
推薦的命名約定是使用大寫的單個字母名稱作為類型參數。對于常見的泛型模式,推薦的名稱是:
- k:鍵,比如映射的鍵
- v:值,比如 list 和 set 的內容,或者 map 中的值
- e:元素
- t:泛型
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public class generic<t> { //key的類型為t private t key; public generic(t key) { //泛型構造方法形參key的類型也為t this .key = key; } public t getkey() { //泛型方法getkey的返回值類型為t return key; } } |
如上定義了一個普通的泛型類,成員變量的類型為 t,t的類型由外部指定。泛型方法和泛型構造函數同樣如此。
1
2
3
4
5
6
|
generic<integer> genericinteger = new generic<integer>( 123456 ); //1 generic<string> genericstring = new generic<string>( "key_vlaue" ); // 2 system.out.println( "key is " + genericinteger.getkey()); system.out.println( "key is " + genericstring.getkey()); |
泛型的類型參數只能是類類型(包括自定義類),不能是簡單類型。傳入的實參類型需與泛型的類型參數類型相同,即為integer/string。
如上所述,定義的泛型類,就一定要傳入泛型類型實參么?
并不是這樣,在使用泛型的時候如果傳入泛型實參,則會根據傳入的泛型實參做相應的限制,此時泛型才會起到本應起到的限制作用。如果不傳入泛型類型實參的話,在泛型類中使用泛型的方法或成員變量定義的類型可以為任何的類型。
1
2
3
4
5
|
generic genericstring = new generic( "111111" ); generic genericinteger = new generic( 4444 ); system.out.println( "key is " + genericstring.getkey()); system.out.println( "key is " + genericinteger.getkey()); |
如上的代碼片段,將會輸出如下的結果:
key is 111111
key is 4444
在不傳入泛型類型實參的情況下,泛型類中使用的泛型防范或成員變量可以為 integer 或 string 等等其他任意類型。不過需要注意的是,泛型的類型參數只能是類類型,不能是簡單類型。且不能對確切的泛型類型使用 instanceof 操作。對于不同傳入的類型實參,生成的相應對象實例的類型是不是一樣的呢?具體看如下的示例:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class generictest { public static void main(string[] args) { generic<integer> name = new box<string>( "111111" ); generic<string> age = new box<integer>( 712 ); system.out.println( "name class:" + name.getclass()); system.out.println( "age class:" + age.getclass()); system.out.println(name.getclass() == age.getclass()); // true } } |
由輸出結構可知,在使用泛型類時,雖然傳入了不同的泛型實參,但并沒有真正意義上生成不同的類型,傳入不同泛型實參的泛型類在內存上只有一個,即還是原來的最基本的類型(本例中為 generic),當然在邏輯上我們可以理解成多個不同的泛型類型。
究其原因,在于 java 中的泛型這一概念提出的目的,其只是作用于代碼編譯階段。在編譯過程中,對于正確檢驗泛型結果后,會將泛型的相關信息擦除。也就是說,成功編譯過后的 class 文件中是不包含任何泛型信息的。泛型信息不會進入到運行時階段。
泛型類型在邏輯上看以看成是多個不同的類型,實際上都是相同的基本類型。
通配符
ingeter 是 number 的一個子類,同時 generic<ingeter> 與 generic<number> 實際上是相同的一種基本類型。那么問題來了,在使用 generic<number> 作為形參的方法中,能否使用generic<ingeter> 的實例傳入呢?在邏輯上類似于 generic<number> 和 generic<ingeter> 是否可以看成具有父子關系的泛型類型呢?下面我們通過定義一個方法來驗證。
1
2
3
|
public void show(generic<number> obj) { system.out.println( "key value is " + obj.getkey()); } |
進行如下的調用
1
2
3
|
generic<integer> genericinteger = new generic<integer>( 123 ); show(genericinteger); //error generic<java.lang.integer> cannot be applied to generic<java.lang.number> |
通過提示信息我們可以看到 generic<integer> 不能被看作為 generic<number> 的子類。由此可以看出:同一種泛型可以對應多個版本(因為參數類型是不確定的),不同版本的泛型類實例是不兼容的。
我們不能因此定義一個 show(generic<integer> obj)來處理,因此我們需要一個在邏輯上可以表示同時是generic和generic父類的引用類型。由此類型通配符應運而生。
t、k、v、e 等泛型字母為有類型,類型參數賦予具體的值。除了有類型,還可以用通配符來表述類型,? 未知類型,類型參數賦予不確定值,任意類型只能用在聲明類型、方法參數上,不能用在定義泛型類上。將方法改寫成如下:
1
2
3
|
public void show(generic<?> obj) { system.out.println( "key value is " + obj.getkey()); } |
此處 ? 是類型實參,而不是類型形參。即和 number、string、integer 一樣都是實際的類型,可以把 ? 看成所有類型的父類,是一種真實的類型。可以解決當具體類型不確定的時候,這個通配符就是 ?;當操作類型時,不需要使用類型的具體功能時,只使用 object 類中的功能。那么可以用 ? 通配符來表未知類型。
泛型上下邊界
在使用泛型的時候,我們還可以為傳入的泛型類型實參進行上下邊界的限制,如:類型實參只準傳入某種類型的父類或某種類型的子類。為泛型添加上邊界,即傳入的類型實參必須是指定類型的子類型。
1
2
3
|
public void show(generic<? extends number> obj) { system.out.println( "key value is " + obj.getkey()); } |
我們在泛型方法的入參限定參數類型為 number 的子類。
1
2
3
4
5
6
|
generic<string> genericstring = new generic<string>( "11111" ); generic<integer> genericinteger = new generic<integer>( 2222 ); showkeyvalue1(genericstring); // error showkeyvalue1(genericinteger); |
當我們的入參為 string 類型時,編譯報錯,因為 string 類型并不是 number 類型的子類。
類型通配符上限通過形如 generic<? extends number> 形式定義;相對應的,類型通配符下限為generic<? super number>形式,其含義與類型通配符上限正好相反,在此不作過多闡述。
泛型數組
在 java 中是不能創建一個確切的泛型類型的數組的,即:
1
|
list<string>[] ls = new arraylist<string>[ 10 ]; |
如上會編譯報錯,而使用通配符創建泛型數組是可以的:
1
2
3
|
list<?>[] ls = new arraylist<?>[ 10 ]; //list<string>[] ls = new arraylist[10]; |
jdk1.7 對泛型的簡化,所以另一種聲明也是可以的。
由于jvm泛型的擦除機制,在運行時 jvm 是不知道泛型信息的。泛型數組實際的運行時對象數組只能是原始類型( t[]為object[],pair[]為pair[] ),而實際的運行時數組對象可能是t類型( 雖然運行時會擦除成原始類型 )。成功創建泛型數組的唯一方式就是創建一個被擦出類型的新數組,然后對其轉型。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class genericarray<t> { private object[] array; //維護object[]類型數組 @supperesswarning ( "unchecked" ) public genericarray( int v) { array = new object[v]; } public void put( int index, t item) { array[index] = item; } public t get( int index) { return (t)array[index]; } //數組對象出口強轉 public t[] rep() { return (t[])array; } //運行時無論怎樣都是object[]類型 public static void main (string[] args){ genericarray<integer> ga = new genericarray<integer>( 10 ); // integer[] ia = ga.rep(); //依舊classcastexception object[] oa = ga.rep(); //只能返回對象數組類型為object[] ga.put( 0 , 11 ); system.out.println(ga.get( 0 )); // 11 } } |
在運行時,數組對象的出口做轉型輸出,入口方法在編譯期已實現類型安全,所以出口方法可以放心強制類型轉換,保證成功。
小結
本文主要講了 java 泛型的相關概念和應用。泛型使編譯器可以在編譯期間對類型進行檢查以提高類型安全,減少運行時由于對象類型不匹配引發的異常。由泛型的誕生介紹相關的概念,在保證代碼質量的情況下,如何使用泛型去簡化開發。
以上所述是小編給大家介紹的java泛型及其應用詳解整合,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回復大家的。在此也非常感謝大家對服務器之家網站的支持!
原文鏈接:https://blog.csdn.net/keets1992/article/details/88955439