Java深度历险(五)——Java泛型
Java泛型(generics)是JDK 5中引入的一個(gè)新特性,允許在定義類和接口的時(shí)候使用類型參數(shù)(type parameter)。聲明的類型參數(shù)在使用時(shí)用具體的類型來替換。泛型最主要的應(yīng)用是在JDK 5中的新集合類框架中。對(duì)于泛型概念的引入,開發(fā)社區(qū)的觀點(diǎn)是褒貶不一。從好的方面來說,泛型的引入可以解決之前的集合類框架在使用過程中通常會(huì)出現(xiàn)的運(yùn)行時(shí)刻類型錯(cuò)誤,因?yàn)榫幾g器可以在編譯時(shí)刻就發(fā)現(xiàn)很多明顯的錯(cuò)誤。而從不好的地方來說,為了保證與舊有版本的兼容性,Java泛型的實(shí)現(xiàn)上存在著一些不夠優(yōu)雅的地方。當(dāng)然這也是任何有歷史的編程語言所需要承擔(dān)的歷史包袱。后續(xù)的版本更新會(huì)為早期的設(shè)計(jì)缺陷所累。??
開發(fā)人員在使用泛型的時(shí)候,很容易根據(jù)自己的直覺而犯一些錯(cuò)誤。比如一個(gè)方法如果接收List<Object>作為形式參數(shù),那么如果嘗試將一個(gè)List<String>的對(duì)象作為實(shí)際參數(shù)傳進(jìn)去,卻發(fā)現(xiàn)無法通過編譯。雖然從直覺上來說,Object是String的父類,這種類型轉(zhuǎn)換應(yīng)該是合理的。但是實(shí)際上這會(huì)產(chǎn)生隱含的類型轉(zhuǎn)換問題,因此編譯器直接就禁止這樣的行為。本文試圖對(duì)Java泛型做一個(gè)概括性的說明。
類型擦除
正確理解泛型概念的首要前提是理解類型擦除(type erasure)。 Java中的泛型基本上都是在編譯器這個(gè)層次來實(shí)現(xiàn)的。在生成的Java字節(jié)代碼中是不包含泛型中的類型信息的。使用泛型的時(shí)候加上的類型參數(shù),會(huì)被編譯器在編譯的時(shí)候去掉。這個(gè)過程就稱為類型擦除。如在代碼中定義的List<Object>和List<String>等類型,在編譯之后都會(huì)變成List。JVM看到的只是List,而由泛型附加的類型信息對(duì)JVM來說是不可見的。Java編譯器會(huì)在編譯時(shí)盡可能的發(fā)現(xiàn)可能出錯(cuò)的地方,但是仍然無法避免在運(yùn)行時(shí)刻出現(xiàn)類型轉(zhuǎn)換異常的情況。類型擦除也是Java的泛型實(shí)現(xiàn)方式與C++模板機(jī)制實(shí)現(xiàn)方式之間的重要區(qū)別。
相關(guān)廠商內(nèi)容
All in AI下的海內(nèi)外架構(gòu)推演
羅輯思維Go語言微服務(wù)改造完整過程
Netflix的未來IT架構(gòu)模型:Serverless
成功靠團(tuán)隊(duì),看一線大廠是如何打造高效技術(shù)團(tuán)隊(duì)的
區(qū)塊鏈浪潮來襲,企業(yè)技術(shù)leader如何理性抉擇?
相關(guān)贊助商
很多泛型的奇怪特性都與這個(gè)類型擦除的存在有關(guān),包括:
- 泛型類并沒有自己獨(dú)有的Class類對(duì)象。比如并不存在List<String>.class或是List<Integer>.class,而只有List.class。
- 靜態(tài)變量是被泛型類的所有實(shí)例所共享的。對(duì)于聲明為MyClass<T>的類,訪問其中的靜態(tài)變量的方法仍然是 MyClass.myStaticVar。不管是通過new MyClass<String>還是new MyClass<Integer>創(chuàng)建的對(duì)象,都是共享一個(gè)靜態(tài)變量。
- 泛型的類型參數(shù)不能用在Java異常處理的catch語句中。因?yàn)楫惓L幚硎怯蒍VM在運(yùn)行時(shí)刻來進(jìn)行的。由于類型信息被擦除,JVM是無法區(qū)分兩個(gè)異常類型MyException<String>和MyException<Integer>的。對(duì)于JVM來說,它們都是 MyException類型的。也就無法執(zhí)行與異常對(duì)應(yīng)的catch語句。
類型擦除的基本過程也比較簡單,首先是找到用來替換類型參數(shù)的具體類。這個(gè)具體類一般是Object。如果指定了類型參數(shù)的上界的話,則使用這個(gè)上界。把代碼中的類型參數(shù)都替換成具體的類。同時(shí)去掉出現(xiàn)的類型聲明,即去掉<>的內(nèi)容。比如T get()方法聲明就變成了Object get();List<String>就變成了List。接下來就可能需要生成一些橋接方法(bridge method)。這是由于擦除了類型之后的類可能缺少某些必須的方法。比如考慮下面的代碼:
class MyString implements Comparable<String> {public int compareTo(String str) { return 0; } }當(dāng)類型信息被擦除之后,上述類的聲明變成了class MyString implements Comparable。但是這樣的話,類MyString就會(huì)有編譯錯(cuò)誤,因?yàn)闆]有實(shí)現(xiàn)接口Comparable聲明的int compareTo(Object)方法。這個(gè)時(shí)候就由編譯器來動(dòng)態(tài)生成這個(gè)方法。
實(shí)例分析
了解了類型擦除機(jī)制之后,就會(huì)明白編譯器承擔(dān)了全部的類型檢查工作。編譯器禁止某些泛型的使用方式,正是為了確保類型的安全性。以上面提到的List<Object>和List<String>為例來具體分析:
public void inspect(List<Object> list) { for (Object obj : list) { System.out.println(obj); } list.add(1); //這個(gè)操作在當(dāng)前方法的上下文是合法的。 } public void test() { List<String> strs = new ArrayList<String>(); inspect(strs); //編譯錯(cuò)誤 }?這段代碼中,inspect方法接受List<Object>作為參數(shù),當(dāng)在test方法中試圖傳入List<String>的時(shí)候,會(huì)出現(xiàn)編譯錯(cuò)誤。假設(shè)這樣的做法是允許的,那么在inspect方法就可以通過list.add(1)來向集合中添加一個(gè)數(shù)字。這樣在test方法看來,其聲明為List<String>的集合中卻被添加了一個(gè)Integer類型的對(duì)象。這顯然是違反類型安全的原則的,在某個(gè)時(shí)候肯定會(huì)拋出ClassCastException。因此,編譯器禁止這樣的行為。編譯器會(huì)盡可能的檢查可能存在的類型安全問題。對(duì)于確定是違反相關(guān)原則的地方,會(huì)給出編譯錯(cuò)誤。當(dāng)編譯器無法判斷類型的使用是否正確的時(shí)候,會(huì)給出警告信息。?
通配符與上下界
在使用泛型類的時(shí)候,既可以指定一個(gè)具體的類型,如List<String>就聲明了具體的類型是String;也可以用通配符?來表示未知類型,如List<?>就聲明了List中包含的元素類型是未知的。 通配符所代表的其實(shí)是一組類型,但具體的類型是未知的。List<?>所聲明的就是所有類型都是可以的。但是List<?>并不等同于List<Object>。List<Object>實(shí)際上確定了List中包含的是Object及其子類,在使用的時(shí)候都可以通過Object來進(jìn)行引用。而List<?>則其中所包含的元素類型是不確定。其中可能包含的是String,也可能是 Integer。如果它包含了String的話,往里面添加Integer類型的元素就是錯(cuò)誤的。正因?yàn)轭愋臀粗?#xff0c;就不能通過new ArrayList<?>()的方法來創(chuàng)建一個(gè)新的ArrayList對(duì)象。因?yàn)榫幾g器無法知道具體的類型是什么。但是對(duì)于 List<?>中的元素確總是可以用Object來引用的,因?yàn)殡m然類型未知,但肯定是Object及其子類。考慮下面的代碼:
public void wildcard(List<?> list) {list.add(1);//編譯錯(cuò)誤 }?如上所示,試圖對(duì)一個(gè)帶通配符的泛型類進(jìn)行操作的時(shí)候,總是會(huì)出現(xiàn)編譯錯(cuò)誤。其原因在于通配符所表示的類型是未知的。
因?yàn)閷?duì)于List<?>中的元素只能用Object來引用,在有些情況下不是很方便。在這些情況下,可以使用上下界來限制未知類型的范圍。 如List<? extends Number>說明List中可能包含的元素類型是Number及其子類。而List<? super Number>則說明List中包含的是Number及其父類。當(dāng)引入了上界之后,在使用類型的時(shí)候就可以使用上界類中定義的方法。比如訪問 List<? extends Number>的時(shí)候,就可以使用Number類的intValue等方法。
類型系統(tǒng)
在Java中,大家比較熟悉的是通過繼承機(jī)制而產(chǎn)生的類型體系結(jié)構(gòu)。比如String繼承自O(shè)bject。根據(jù)Liskov替換原則,子類是可以替換父類的。當(dāng)需要Object類的引用的時(shí)候,如果傳入一個(gè)String對(duì)象是沒有任何問題的。但是反過來的話,即用父類的引用替換子類引用的時(shí)候,就需要進(jìn)行強(qiáng)制類型轉(zhuǎn)換。編譯器并不能保證運(yùn)行時(shí)刻這種轉(zhuǎn)換一定是合法的。這種自動(dòng)的子類替換父類的類型轉(zhuǎn)換機(jī)制,對(duì)于數(shù)組也是適用的。 String[]可以替換Object[]。但是泛型的引入,對(duì)于這個(gè)類型系統(tǒng)產(chǎn)生了一定的影響。正如前面提到的List<String>是不能替換掉List<Object>的。
引入泛型之后的類型系統(tǒng)增加了兩個(gè)維度:一個(gè)是類型參數(shù)自身的繼承體系結(jié)構(gòu),另外一個(gè)是泛型類或接口自身的繼承體系結(jié)構(gòu)。第一個(gè)指的是對(duì)于 List<String>和List<Object>這樣的情況,類型參數(shù)String是繼承自O(shè)bject的。而第二種指的是 List接口繼承自Collection接口。對(duì)于這個(gè)類型系統(tǒng),有如下的一些規(guī)則:
- 相同類型參數(shù)的泛型類的關(guān)系取決于泛型類自身的繼承體系結(jié)構(gòu)。即List<String>是Collection<String> 的子類型,List<String>可以替換Collection<String>。這種情況也適用于帶有上下界的類型聲明。
- 當(dāng)泛型類的類型聲明中使用了通配符的時(shí)候, 其子類型可以在兩個(gè)維度上分別展開。如對(duì)Collection<? extends Number>來說,其子類型可以在Collection這個(gè)維度上展開,即List<? extends Number>和Set<? extends Number>等;也可以在Number這個(gè)層次上展開,即Collection<Double>和 Collection<Integer>等。如此循環(huán)下去,ArrayList<Long>和 HashSet<Double>等也都算是Collection<? extends Number>的子類型。
- 如果泛型類中包含多個(gè)類型參數(shù),則對(duì)于每個(gè)類型參數(shù)分別應(yīng)用上面的規(guī)則。
理解了上面的規(guī)則之后,就可以很容易的修正實(shí)例分析中給出的代碼了。只需要把List<Object>改成List<?>即可。List<String>是List<?>的子類型,因此傳遞參數(shù)時(shí)不會(huì)發(fā)生錯(cuò)誤。
開發(fā)自己的泛型類
泛型類與一般的Java類基本相同,只是在類和接口定義上多出來了用<>聲明的類型參數(shù)。一個(gè)類可以有多個(gè)類型參數(shù),如 MyClass<X, Y, Z>。 每個(gè)類型參數(shù)在聲明的時(shí)候可以指定上界。所聲明的類型參數(shù)在Java類中可以像一般的類型一樣作為方法的參數(shù)和返回值,或是作為域和局部變量的類型。但是由于類型擦除機(jī)制,類型參數(shù)并不能用來創(chuàng)建對(duì)象或是作為靜態(tài)變量的類型??紤]下面的泛型類中的正確和錯(cuò)誤的用法。
class ClassTest<X extends Number, Y, Z> { private X x; private static Y y; //編譯錯(cuò)誤,不能用在靜態(tài)變量中 public X getFirst() {//正確用法 return x; } public void wrong() { Z z = new Z(); //編譯錯(cuò)誤,不能創(chuàng)建對(duì)象 } }?最佳實(shí)踐
在使用泛型的時(shí)候可以遵循一些基本的原則,從而避免一些常見的問題。
- 在代碼中避免泛型類和原始類型的混用。比如List<String>和List不應(yīng)該共同使用。這樣會(huì)產(chǎn)生一些編譯器警告和潛在的運(yùn)行時(shí)異常。當(dāng)需要利用JDK 5之前開發(fā)的遺留代碼,而不得不這么做時(shí),也盡可能的隔離相關(guān)的代碼。
- 在使用帶通配符的泛型類的時(shí)候,需要明確通配符所代表的一組類型的概念。由于具體的類型是未知的,很多操作是不允許的。
- 泛型類最好不要同數(shù)組一塊使用。你只能創(chuàng)建new List<?>[10]這樣的數(shù)組,無法創(chuàng)建new List<String>[10]這樣的。這限制了數(shù)組的使用能力,而且會(huì)帶來很多費(fèi)解的問題。因此,當(dāng)需要類似數(shù)組的功能時(shí)候,使用集合類即可。
- 不要忽視編譯器給出的警告信息。
參考資料
- Generics gotchas
- Java Generics FAQs
- Generics in Java Programming Language
總結(jié)
以上是生活随笔為你收集整理的Java深度历险(五)——Java泛型的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Javassist 使用指南(一)
- 下一篇: 泛型:工作原理及其重要性