面試官:兄弟,說說基本類型和包裝類型的區別吧

六年前,我從蘇州回到洛陽,抱着一幅「海歸」的心態,投了很多簡歷,也「約談」了很多面試官,但僅有兩三個令我感到滿意。其中有一位叫老馬,至今還活在個人手機通信錄裏。他當時扔了一個面試題把我砸懵了:說說基本類型和包裝類型的區別吧。java

我當時二十三歲,正值青春年華,從事 Java 編程已有 N 年經驗(N < 4),自認爲全部的面試題都能對答如流,結果沒想到啊,被「刁難」了——原來洛陽這塊互聯網的荒漠也有技術專家啊。如今回想起來,臉上不自覺地泛起了羞愧的紅暈:主要是本身當時太菜了。無論怎麼說,是時候寫篇文章剖析一下基本類型和包裝類型的區別了。面試

Java 的每一個基本類型都對應了一個包裝類型,好比說 int 的包裝類型爲 Integer,double 的包裝類型爲 Double。基本類型和包裝類型的區別主要有如下 4 點。數據庫

0一、包裝類型能夠爲 null,而基本類型不能夠

別小看這一點區別,它使得包裝類型能夠應用於 POJO 中,而基本類型則不行。編程

POJO 是什麼呢?這裏稍微說明一下。緩存

POJO 的英文全稱是 Plain Ordinary Java Object,翻譯一下就是,簡單無規則的 Java 對象,只有屬性字段以及 setter 和 getter 方法,示例以下。markdown

class Writer {
	private Integer age;
	private String name;

	public Integer getAge() {
		return age;
	}

	public void setAge(Integer age) {
		this.age = age;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
}
複製代碼

和 POJO 相似的,還有數據傳輸對象 DTO(Data Transfer Object,泛指用於展現層與服務層之間的數據傳輸對象)、視圖對象 VO(View Object,把某個頁面的數據封裝起來)、持久化對象 PO(Persistant Object,能夠當作是與數據庫中的表映射的 Java 對象)。性能

那爲何 POJO 的屬性必需要用包裝類型呢?this

《阿里巴巴 Java 開發手冊》上有詳細的說明,咱們來大聲朗讀一下(預備,起)。spa

數據庫的查詢結果多是 null,若是使用基本類型的話,由於要自動拆箱(將包裝類型轉爲基本類型,好比說把 Integer 對象轉換成 int 值),就會拋出 NullPointerException 的異常。翻譯

0二、包裝類型可用於泛型,而基本類型不能夠

泛型不能使用基本類型,由於使用基本類型時會編譯出錯。

List<int> list = new ArrayList<>(); // 提示 Syntax error, insert "Dimensions" to complete ReferenceType
List<Integer> list = new ArrayList<>();
複製代碼

爲何呢?由於泛型在編譯時會進行類型擦除,最後只保留原始類型,而原始類型只能是 Object 類及其子類——基本類型是個特例。

0三、基本類型比包裝類型更高效

基本類型在棧中直接存儲的具體數值,而包裝類型則存儲的是堆中的引用。

很顯然,相比較於基本類型而言,包裝類型須要佔用更多的內存空間。假如沒有基本類型的話,對於數值這類常用到的數據來講,每次都要經過 new 一個包裝類型就顯得很是笨重。

0三、兩個包裝類型的值能夠相同,但卻不相等

兩個包裝類型的值能夠相同,但卻不相等——這句話怎麼理解呢?來看一段代碼就明明白白了。

Integer chenmo = new Integer(10);
Integer wanger = new Integer(10);

System.out.println(chenmo == wanger); // false
System.out.println(chenmo.equals(wanger )); // true
複製代碼

兩個包裝類型在使用「==」進行判斷的時候,判斷的是其指向的地址是否相等。chenmo 和 wanger 兩個變量使用了 new 關鍵字,致使它們在「==」的時候輸出了 false。

chenmo.equals(wanger) 的輸出結果爲 true,是由於 equals 方法內部比較的是兩個 int 值是否相等。源碼以下。

private final int value;

public int intValue() {
    return value;
}
public boolean equals(Object obj) {
    if (obj instanceof Integer) {
        return value == ((Integer)obj).intValue();
    }
    return false;
}
複製代碼

瞧,雖然 chenmo 和 wanger 的值都是 10,但他們並不相等。換句話說就是:將「==」操做符應用於包裝類型比較的時候,其結果極可能會和預期的不符

0四、自動裝箱和自動拆箱

既然有了基本類型和包裝類型,確定有些時候要在它們之間進行轉換。把基本類型轉換成包裝類型的過程叫作裝箱(boxing)。反之,把包裝類型轉換成基本類型的過程叫作拆箱(unboxing)。

在 Java SE5 以前,開發人員要手動進行裝拆箱,好比說:

Integer chenmo = new Integer(10);  // 手動裝箱
int wanger = chenmo.intValue();  // 手動拆箱
複製代碼

Java SE5 爲了減小開發人員的工做,提供了自動裝箱與自動拆箱的功能。

Integer chenmo  = 10;  // 自動裝箱
int wanger = chenmo;     // 自動拆箱
複製代碼

上面這段代碼使用 JAD 反編譯後的結果以下所示:

Integer chenmo = Integer.valueOf(10);
int wanger = chenmo.intValue();
複製代碼

也就是說,自動裝箱是經過 Integer.valueOf() 完成的;自動拆箱是經過 Integer.intValue() 完成的。理解了原理以後,咱們再來看一道老馬當年給我出的面試題。

// 1)基本類型和包裝類型
int a = 100;
Integer b = 100;
System.out.println(a == b);

// 2)兩個包裝類型
Integer c = 100;
Integer d = 100;
System.out.println(c == d);

// 3)
c = 200;
d = 200;
System.out.println(c == d);
複製代碼

答案是什麼呢?有舉手要回答的嗎?答對的獎勵一朵小紅花哦。

第一段代碼,基本類型和包裝類型進行 == 比較,這時候 b 會自動拆箱,直接和 a 比較值,因此結果爲 true。

第二段代碼,兩個包裝類型都被賦值爲了 100,這時候會進行自動裝箱,那 == 的結果會是什麼呢?

咱們以前的結論是:將「==」操做符應用於包裝類型比較的時候,其結果極可能會和預期的不符。那結果是 false?但此次的結果倒是 true,是否是感受很意外?

第三段代碼,兩個包裝類型從新被賦值爲了 200,這時候仍然會進行自動裝箱,那 == 的結果會是什麼呢?

吃了第二段代碼的虧後,是否是有點懷疑人生了,此次結果是 true 仍是 false 呢?扔個硬幣吧,哈哈。我先告訴你結果吧,false。

爲何?爲何?爲何呢?

事情到了這一步,必須使出殺手鐗了——分析源碼吧。

以前咱們已經知道了,自動裝箱是經過 Integer.valueOf() 完成的,那咱們就來看看這個方法的源碼吧。

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}
複製代碼

難不成是 IntegerCache 在做怪?你猜對了!

private static class IntegerCache {
    static final int low = -128;
    static final int high;
    static final Integer cache[];

    static {
        // high value may be configured by property
        int h = 127;
        int i = parseInt(integerCacheHighPropValue);
        i = Math.max(i, 127);
        h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
        high = h;

        cache = new Integer[(high - low) + 1];
        int j = low;
        for(int k = 0; k < cache.length; k++)
            cache[k] = new Integer(j++);

        // range [-128, 127] must be interned (JLS7 5.1.7)
        assert IntegerCache.high >= 127;
    }
}
複製代碼

大體瞟一下這段代碼你就全明白了。-128 到 127 之間的數會從 IntegerCache 中取,而後比較,因此第二段代碼(100 在這個範圍以內)的結果是 true,而第三段代碼(200 不在這個範圍以內,因此 new 出來了兩個 Integer 對象)的結果是 false。

看完上面的分析以後,我但願你們記住一點:當須要進行自動裝箱時,若是數字在 -128 至 127 之間時,會直接使用緩存中的對象,而不是從新建立一個對象

自動裝拆箱是一個很好的功能,大大節省了咱們開發人員的精力,但也會引起一些麻煩,好比下面這段代碼,性能就不好。

long t1 = System.currentTimeMillis();
Long sum = 0L;
for (int i = 0; i < Integer.MAX_VALUE;i++) {
    sum += i;
}
long t2 = System.currentTimeMillis();        
System.out.println(t2-t1);
複製代碼

sum 因爲被聲明成了包裝類型 Long 而不是基本類型 long,因此 sum += i 進行了大量的拆裝箱操做(sum 先拆箱和 i 相加,而後再裝箱賦值給 sum),致使這段代碼運行完花費的時間足足有 2986 毫秒;若是把 sum 換成基本類型 long,時間就僅有 554 毫秒,徹底不一個等量級啊。

0五、最後

謝謝你們的閱讀,原創不易,喜歡就點個贊,這將是我最強的寫做動力。若是你以爲文章對你有所幫助,也蠻有趣的,就關注一下個人公衆號,謝謝。

PS:偷偷地告訴你,後臺回覆「Java」還可領取價值 399 元的 Java 進階資料,噓。

相關文章
相關標籤/搜索