面試官：兄弟，說說基本類型和包裝類型的區(qū)別吧

六年前，我從蘇州回到洛陽，抱著一幅“海歸”的心態(tài)，投了不少簡歷，也“約談”了不少面試官，但僅有兩三個令我感到滿意。其中有一位叫老馬，至今還活在我的手機通訊錄里。他當時扔了一個面試題把我砸懵了：說說基本類型和包裝類型的區(qū)別吧。

我當時二十三歲，正值青春年華，從事 Java 編程已有 N 年經(jīng)驗（N <
4），自認為所有的面試題都能對答如流，結(jié)果沒想到啊，被“刁難”了——原來洛陽這塊互聯(lián)網(wǎng)的荒漠也有技術(shù)專家啊?，F(xiàn)在回想起來，臉上不自覺地泛起了羞愧的紅暈：主要是自己當時太菜了。不管怎么說，是時候?qū)懫恼缕饰鲆幌禄绢愋秃桶b類型的區(qū)別了。

Java 的每個基本類型都對應(yīng)了一個包裝類型，比如說 int 的包裝類型為 Integer，double 的包裝類型為
Double?；绢愋秃桶b類型的區(qū)別主要有以下 4 點。

01、包裝類型可以為 null，而基本類型不可以

別小看這一點區(qū)別，它使得包裝類型可以應(yīng)用于 POJO 中，而基本類型則不行。

POJO 是什么呢？這里稍微說明一下。

POJO 的英文全稱是 Plain Ordinary Java Object，翻譯一下就是，簡單無規(guī)則的 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 類似的，還有數(shù)據(jù)傳輸對象 DTO（Data Transfer Object，泛指用于展示層與服務(wù)層之間的數(shù)據(jù)傳輸對象）、視圖對象
VO（View Object，把某個頁面的數(shù)據(jù)封裝起來）、持久化對象 PO（Persistant Object，可以看成是與數(shù)據(jù)庫中的表映射的 Java
對象）。

那為什么 POJO 的屬性必須要用包裝類型呢？

《阿里巴巴 Java 開發(fā)手冊》上有詳細的說明，我們來大聲朗讀一下（預(yù)備，起）。

數(shù)據(jù)庫的查詢結(jié)果可能是 null，如果使用基本類型的話，因為要自動拆箱（將包裝類型轉(zhuǎn)為基本類型，比如說把 Integer 對象轉(zhuǎn)換成 int 值），就會拋出
NullPointerException 的異常。

02、包裝類型可用于泛型，而基本類型不可以

泛型不能使用基本類型，因為使用基本類型時會編譯出錯。
List<int>?list?=?new?ArrayList<>();?
//?提示?Syntax?error,?insert?"Dimensions"?to?complete?ReferenceType
List<Integer>?list?=?new?ArrayList<>();

為什么呢？因為泛型在編譯時會進行類型擦除，最后只保留原始類型，而原始類型只能是 Object 類及其子類——基本類型是個特例。

03、基本類型比包裝類型更高效

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



?

?

很顯然，相比較于基本類型而言，包裝類型需要占用更多的內(nèi)存空間。假如沒有基本類型的話，對于數(shù)值這類經(jīng)常使用到的數(shù)據(jù)來說，每次都要通過 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
關(guān)鍵字，導致它們在“==”的時候輸出了 false。

而 chenmo.equals(wanger) 的輸出結(jié)果為 true，是因為 equals 方法內(nèi)部比較的是兩個 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，但他們并不相等。換句話說就是：將“==”操作符應(yīng)用于包裝類型比較的時候，其結(jié)果很可能會和預(yù)期的不符。

04、自動裝箱和自動拆箱


既然有了基本類型和包裝類型，肯定有些時候要在它們之間進行轉(zhuǎn)換。把基本類型轉(zhuǎn)換成包裝類型的過程叫做裝箱（boxing）。反之，把包裝類型轉(zhuǎn)換成基本類型的過程叫做拆箱（unboxing）。

在 Java SE5 之前，開發(fā)人員要手動進行裝拆箱，比如說：
Integer?chenmo?=?new?Integer(10);??//?手動裝箱
int?wanger?=?chenmo.intValue();??//?手動拆箱

Java SE5 為了減少開發(fā)人員的工作，提供了自動裝箱與自動拆箱的功能。
Integer?chenmo??=?10;??//?自動裝箱
int?wanger?=?chenmo;?????//?自動拆箱

上面這段代碼使用 JAD 反編譯后的結(jié)果如下所示：
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 比較值，所以結(jié)果為 true。

第二段代碼，兩個包裝類型都被賦值為了 100，這時候會進行自動裝箱，那 == 的結(jié)果會是什么呢？

我們之前的結(jié)論是：將“==”操作符應(yīng)用于包裝類型比較的時候，其結(jié)果很可能會和預(yù)期的不符。那結(jié)果是 false？但這次的結(jié)果卻是 true，是不是感覺很意外？

第三段代碼，兩個包裝類型重新被賦值為了 200，這時候仍然會進行自動裝箱，那 == 的結(jié)果會是什么呢？

吃了第二段代碼的虧后，是不是有點懷疑人生了，這次結(jié)果是 true 還是 false 呢？扔個硬幣吧，哈哈。我先告訴你結(jié)果吧，false。

為什么？為什么？為什么呢？

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

之前我們已經(jīng)知道了，自動裝箱是通過 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 之間的數(shù)會從 IntegerCache 中取，然后比較，所以第二段代碼（100
在這個范圍之內(nèi)）的結(jié)果是 true，而第三段代碼（200 不在這個范圍之內(nèi)，所以 new 出來了兩個 Integer 對象）的結(jié)果是 false。

看完上面的分析之后，我希望大家記住一點：當需要進行自動裝箱時，如果數(shù)字在 -128 至 127 之間時，會直接使用緩存中的對象，而不是重新創(chuàng)建一個對象。

自動裝拆箱是一個很好的功能，大大節(jié)省了我們開發(fā)人員的精力，但也會引發(fā)一些麻煩，比如下面這段代碼，性能就很差。
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
毫秒，完全不一個等量級啊。

?

?

• ? 上一篇： 筆記：Docker命令自動補全
• ? 下一篇： Cassandra sstableloader工具使用及原理解析