面试官：兄弟，说说基本类型和包装类型的区别吧

六年前，我从苏州回到洛阳，抱着一幅“海归”的心态，投了很多简历，也“约谈”了很多面试官，但仅有两三个令我感到满意。其中有一位叫老马，至今还活在个人手机通信录里。他当时扔了一个面试题把我砸懵了：说说基本类型和包装类型的区别吧。

我当时二十三岁，正值青春年华，从事 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...