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

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

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

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

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

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

POJO 是什麼呢？這裏稍微說明一下。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

？爲何？爲何呢？

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

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

難不成是 IntegerCache 在做怪？你猜對了！

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

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

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

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

原文連接：https://mp.weixin.qq.com/s/JE...