六年前,我從蘇州回到洛陽,抱着一幅“海歸”的心态,投了不少履歷,也“約談”了不少面試官,但僅有兩三個令我感到滿意。其中有一位叫老馬,至今還活在我的手機通訊錄裡。他當時扔了一個面試題把我砸懵了:說說基本類型和包裝類型的差別吧。
我當時二十三歲,正值青春年華,從事 Java 程式設計已有 N 年經驗(N < 4),自認為所有的面試題都能對答如流,結果沒想到啊,被“刁難”了——原來洛陽這塊網際網路的荒漠也有技術專家啊。現在回想起來,臉上不自覺地泛起了羞愧的紅暈:主要是自己當時太菜了。不管怎麼說,是時候寫篇文章剖析一下基本類型和包裝類型的差別了。
Java 的每個基本類型都對應了一個包裝類型,比如說 int 的包裝類型為 Integer,double 的包裝類型為 Double。基本類型和包裝類型的差別主要有以下 4 點。
01、包裝類型可以為 null,而基本類型不可以
别小看這一點差別,它使得包裝類型可以應用于 POJO 中,而基本類型則不行。
POJO 是什麼呢?這裡稍微說明一下。
POJO 的英文全稱是
Plain Ordinary Java Object
,翻譯一下就是,簡單無規則的 Java 對象,隻有屬性字段以及 setter 和 getter 方法,示例如下。
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 的屬性必須要用包裝類型呢?
《阿裡巴巴 Java 開發手冊》上有詳細的說明,我們來大聲朗讀一下(預備,起)。
資料庫的查詢結果可能是 null,如果使用基本類型的話,因為要自動拆箱(将包裝類型轉為基本類型,比如說把 Integer 對象轉換成 int 值),就會抛出 NullPointerException
的異常。
02、包裝類型可用于泛型,而基本類型不可以
泛型不能使用基本類型,因為使用基本類型時會編譯出錯。
List<int> list = new ArrayList<>(); // 提示 Syntax error, insert "Dimensions" to complete ReferenceType
List<Integer> list = new ArrayList<>();
為什麼呢?因為泛型在編譯時會進行類型擦除,最後隻保留原始類型,而原始類型隻能是 Object 類及其子類——基本類型是個特例。
03、基本類型比包裝類型更高效
基本類型在棧中直接存儲的具體數值,而包裝類型則存儲的是堆中的引用。
很顯然,相比較于基本類型而言,包裝類型需要占用更多的記憶體空間。假如沒有基本類型的話,對于數值這類經常使用到的資料來說,每次都要通過 new 一個包裝類型就顯得非常笨重。
03、兩個包裝類型的值可以相同,但卻不相等
兩個包裝類型的值可以相同,但卻不相等——這句話怎麼了解呢?來看一段代碼就明明白白了。
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,但他們并不相等。換句話說就是:将“==”操作符應用于包裝類型比較的時候,其結果很可能會和預期的不符。
04、自動裝箱和自動拆箱
既然有了基本類型和包裝類型,肯定有些時候要在它們之間進行轉換。把基本類型轉換成包裝類型的過程叫做裝箱(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 毫秒,完全不一個等量級啊。