JVM如何理解Java泛型類(轉)


一個很典型的泛型(generic)代碼。T是類型變量,可以是任何引用類型:

public class Pair<T>{  
       private T first=null;  
       private T second=null;  
  
       public Pair(T fir,T sec){  
            this.first=fir;  
        this.second=sec;  
       }  
       public T getFirst(){  
             return this.first;  
       }  
       public T getSecond(){  
             return this.second;  
       }  
       public void setFirst(T fir){  
         this.first=fir;  
       }  
}  

 

1、Generic class 創建對象 

            Pair<String> pair1=new Pair("string",1);           ...①
            Pair<String> pair2=new Pair<String>("string",1)    ...②

有個很有趣的現象:  ①代碼在編譯期不會出錯,②代碼在編譯期會檢查出錯誤。 
這個問題其實很簡單
      (1) JVM本身並沒有泛型對象這樣的一個特殊概念。所有的泛型類對象在編譯器會全部變成普通類對象(這一點會在下面詳細闡述)。
      比如①,②兩個代碼編譯器全部調用的是 Pair(Object fir, Object sec)這樣的構造器。

      因此代碼①中的new Pair("string",1)在編譯器是沒有問題的,畢竟編譯器並不知道你創建的Pair類型中具體是哪一個類型變量T,而且編譯器肯定了String對象和Integer對象都屬於Object類型的。

       但是一段運行pair1.getSecond()就會拋出ClassCastException異常。這是因為JVM會根據第一個參數"string"推算出T類型變量是String類型,這樣getSecond也應該是返回String類型,然后編譯器已經默認了second的操作數是一個值為1的Integer類型。當然就不符合JVM的運行要求了,不終止程序才怪。


       (2) 但代碼②會在編譯器報錯,是因為new Pair<String>("string",1)已經指明了創建對象pair2的類型變量T應該是String的。所以在編譯期編譯器就知道錯誤出在第二個參數Integer了。


小結一下: 
       創建泛型對象的時候,一定要指出類型變量T的具體類型。爭取讓編譯器檢查出錯誤,而不是留給JVM運行的時候拋出異常。

 

2、JVM如何理解泛型概念 —— 類型擦除 
    事實上,JVM並不知道泛型,所有的泛型在編譯階段就已經被處理成了普通類和方法。 
    處理方法很簡單,我們叫做類型變量T的擦除(erased) 
    無論我們如何定義一個泛型類型,相應的都會有一個原始類型被自動提供。原始類型的名字就是擦除類型參數的泛型類型的名字。
         如果泛型類型的類型變量沒有限定(<T>) ,那么我們就用Object作為原始類型;
         如果有限定(<T extends XClass>),我們就XClass作為原始類型;
         如果有多個限定(<T extends XClass1&XClass2>),我們就用第一個邊界的類型變量XClass1類作為原始類型;
 
    比如上面的Pair<T>例子,編譯器會把它當成被Object原始類型替代的普通類來替代。

 

//編譯階段:類型變量的擦除  
public class Pair{  
       private Object first=null;  
       private Object second=null;  
  
       public Pair(Object fir,Object sec){  
           this.first=fir;  
           this.second=sec;  
       }  
      public Object getFirst(){  
           return this.first;  
      }  
      public void setFirst(Object fir){  
           this.first=fir;  
      }  
   }  

 

3、泛型約束和局限性—— 類型擦除所帶來的麻煩

(1)  繼承泛型類型的多態麻煩。(—— 子類沒有覆蓋住父類的方法 )

     看看下面這個類SonPair

class SonPair extends Pair<String>{  
          public void setFirst(String fir){....}  
}  

 很明顯,程序員的本意是想在SonPair類中覆蓋父類Pair<String>的setFirst(T fir)這個方法。但事實上,SonPair中的setFirst(String fir)方法根本沒有覆蓋住Pair<String>中的這個方法。 
     原因很簡單,Pair<String>在編譯階段已經被類型擦除為Pair了,它的setFirst方法變成了setFirst(Object fir)。 那么SonPair中setFirst(String)當然無法覆蓋住父類的setFirst(Object)了。

這對於多態來說確實是個不小的麻煩,我們看看編譯器是如何解決這個問題的。

編譯器 會自動在 SonPair中生成一個橋方法(bridge method ) : 
           public void setFirst(Object fir){
                   setFirst((String) fir)
            } 

這樣,SonPair的橋方法確實能夠覆蓋泛型父類的setFirst(Object) 了。而且橋方法內部其實調用的是子類字節setFirst(String)方法。對於多態來說就沒問題了。

 問題還沒有完,多態中的方法覆蓋是可以了,但是橋方法卻帶來了一個疑問:

 

現在,假設 我們還想在 SonPair 中覆蓋getFirst()方法呢?

class SonPair extends Pair<String>{  
      public String getFirst(){....}  
}  

 由於需要橋方法來覆蓋父類中的getFirst,編譯器會自動在SonPair中生成一個 public Object getFirst()橋方法。 
 但是,疑問來了,SonPair中出現了兩個方法簽名一樣的方法(只是返回類型不同):

            ①String getFirst()   // 自己定義的方法
            ②Object getFirst()  //  編譯器生成的橋方法 

      難道,編譯器允許出現方法簽名相同的多個方法存在於一個類中嗎?

      事實上有一個知識點可能大家都不知道:
      ① 方法簽名 確實只有方法名+參數列表 。這毫無疑問!
      ② 我們絕對不能編寫出方法簽名一樣的多個方法 。如果這樣寫程序,編譯器是不會放過的。這也毫無疑問!
      ③ 最重要的一點是:JVM會用參數類型和返回類型來確定一個方法。 一旦編譯器通過某種方式自己編譯出方法簽名一樣的兩個方法(只能編譯器自己來創造這種奇跡,我們程序員卻不能人為的編寫這種代碼)。JVM還是能夠分清楚這些方法的,前提是需要返回類型不一樣。

 

(2) 泛型類型中的方法沖突

//在上面代碼中加入equals方法  
public class Pair<T>{  
      public boolean equals(T value){  
            return (first.equals(value));  
      }  
}  

這樣看似乎沒有問題的代碼連編譯器都通過不了:

       【Error】    Name clash: The method equals(T) of type Pair<T> has the same erasure as equals(Object) of type Object but does not override it。

        編譯器說你的方法與Object中的方法沖突了。這是為什么?

        開始我也不太明白這個問題,覺得好像編譯器幫助我們使得equals(T)這樣的方法覆蓋上了Object中的equals(Object)。經過大家的討論,我覺得應該這么解釋這個問題?

        首先、我們都知道子類方法要覆蓋,必須與父類方法具有相同的方法簽名(方法名+參數列表)。而且必須保證子類的訪問權限>=父類的訪問權限。這是大家都知道的事實。

        然后、在上面的代碼中,當編譯器看到Pair<T>中的equals(T)方法時,第一反應當然是equals(T)沒有覆蓋住父類Object中的equals(Object)了。

        接着、編譯器將泛型代碼中的T用Object替代(擦除)。突然發現擦除以后equals(T)變成了equals(Object),糟糕了,這個方法與Object類中的equals一樣了。基於開始確定沒有覆蓋這樣一個想法,編譯器徹底的瘋了(精神分裂)。然后得出兩個結論:①堅持原來的思想:沒有覆蓋。但現在一樣造成了方法沖突了。   ②寫這程序的程序員瘋了(哈哈)。

        再說了,拿Pair<T>對象和T對象比較equals,就像牛頭對比馬嘴,哈哈,邏輯上也不通呀。

(3) 沒有泛型數組一說

      Pair<String>[] stringPairs=new Pair<String>[10];
      Pair<Integer>[] intPairs=new Pair<Integer>[10];

      這種寫法編譯器會指定一個Cannot create a generic array of Pair<String>的錯誤

      我們說過泛型擦除之后,Pair<String>[]會變成Pair[],進而又可以轉換為Object[];

      假設泛型數組存在,那么

            Object[0]=stringPairs[0]; Ok
            Object[1]=intPairs[0]; Ok

       這就麻煩了,理論上將Object[]可以存儲所有Pair對象,但這些Pair對象是泛型對象,他們的類型變量都不一樣,那么調用每一個Object[]數組元素的對象方法可能都會得到不同的記過,也許是個字符串,也許是整形,這對於JVM可是無法預料的。

      記住: 數組必須牢記它的元素類型,也就是所有的元素對象都必須一個樣,泛型類型恰恰做不到這一點。即使Pair<String>,Pair<Integer>... 都是Pair類型的,但他們還是不一樣。


總結:泛型代碼與JVM 
    ① 虛擬機中沒有泛型,只有普通類和方法。
    ② 在編譯階段,所有泛型類的類型參數都會被Object或者它們的限定邊界來替換。(類型擦除)
    ③ 在繼承泛型類型的時候,橋方法的合成是為了避免類型變量擦除所帶來的多態災難。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM