真实面经题目 · 原创解析
Java 基本数据类型是直接表达值的类型，包括 byte、short、int、long、float、double、char、boolean；包装类是对应的引用类型，包括 Byte、Short、Integer、Long、Float、Double、Character、Boolean。核心区别在于：基本类型没有对象身份、不能为 null、不能用于泛型；包装类有对象语义、可以为 null、能进入集合和泛型体系，但会带来装箱拆箱、缓存池、对象开销、NPE 和比较语义等问题。
面试里可以从四个层次回答。第一，语义上基本类型存的是值，没有对象身份；包装类是对象引用，有对象头、方法、类型信息，可以为 null。第二，使用场景上，基本类型适合计算和字段值表达，包装类适合泛型、集合、反射、序列化框架以及需要三态含义的字段。第三，运行机制上，自动装箱和拆箱只是编译器语法糖，例如 int 到 Integer 通常会调用 Integer.valueOf，Integer 到 int 会调用 intValue，拆箱 null 会抛 NullPointerException。第四，比较和性能上，基本类型用 == 比值；包装类用 == 可能比引用，应该用 equals 或先明确拆箱，同时注意 Integer 等包装类存在缓存池，缓存范围内的 == 结果容易误导。实际编码中，能用基本类型表达且不需要 null、泛型或框架绑定时优先用基本类型；需要集合、泛型、数据库字段缺失语义或对象协议时使用包装类，并显式处理 null。
基本数据类型是 Java 语言内建的值类型，变量直接表示一个具体值，例如 int 表示 32 位有符号整数，boolean 表示真假。它们没有对象身份，不继承 Object，不能调用实例方法，也没有 equals、hashCode 这类对象协议。包装类则是引用类型，本质上是对象，变量保存的是对象引用，真正的数据在对象内部字段中。包装类拥有对象头、类型信息、方法、接口实现，能够参与 Object 体系，例如 Integer 实现了 Comparable、Serializable 等接口。因此两者不是简单的语法差异，而是值语义与对象语义的差异。
基本类型的值通常存放在变量所在的位置：局部变量在栈帧的局部变量表中，作为对象字段时嵌入对象实例中，作为数组元素时连续存放在基本类型数组中。包装类变量本身是引用，引用指向堆上的包装对象，包装对象除了保存实际数值外，还包含对象头、对齐填充等额外开销。以 Integer 为例，逻辑上只包装一个 int，但对象本身的内存占用明显大于 4 字节。现代 JIT 可能通过逃逸分析、标量替换消除某些临时包装对象，但这是优化结果，不应作为代码语义依赖。高频计算、海量数组、热点循环里优先使用基本类型，通常更省内存也更稳定。
基本类型不能为 null。作为类字段或数组元素时会有默认值：byte、short、int、long 默认是 0，float、double 默认是 0.0，char 默认是 '\u0000'，boolean 默认是 false。局部变量无论是基本类型还是引用类型，都必须显式初始化后才能使用。包装类作为引用类型，字段和数组元素默认值是 null。这个差异很关键：如果业务上需要区分值为 0 和没有值，包装类更合适；如果字段天然必有值，使用基本类型可以避免空值分支和拆箱 NPE。
Java 泛型只能使用引用类型，不能直接写 List<int>、Map<long, double>，因此集合中必须使用 Integer、Long、Double 等包装类。这与 Java 泛型的设计和类型擦除有关，擦除后的类型需要按引用对象处理。集合、Optional、Stream 的泛型参数、反射 API、很多序列化和 ORM 框架也都更自然地使用包装类型。不过这并不意味着所有数据结构都应该使用包装类；如果是大量数值计算，int[]、long[]、double[] 这类基本类型数组通常比 List<Integer> 更节省内存、更少装箱、更有缓存友好性。
自动装箱是编译器把基本类型转换成包装类的语法糖，例如把 int 赋给 Integer 时会转换为 Integer.valueOf(value)。自动拆箱是把包装类转换成基本类型，例如把 Integer 参与 int 计算时会调用 intValue。它让代码更简洁，但不会改变底层语义：包装类仍可能是 null，拆箱 null 会抛 NullPointerException；装箱也可能产生对象或复用缓存对象；循环中频繁装箱拆箱会带来额外开销。面试中要强调，自动装箱拆箱不是运行时魔法，而是编译期插入方法调用。
部分包装类的 valueOf 方法会复用缓存对象。常见规则是 Byte 全部缓存，Boolean 缓存 TRUE 和 FALSE，Short、Integer、Long 默认缓存 -128 到 127，Character 默认缓存 0 到 127。Integer 的上界在一些 JVM 参数下可以调整，但不能把缓存池当作业务逻辑依据。Float 和 Double 通常没有类似整数包装类的缓存池。缓存池会影响包装类使用 == 比较时的结果，例如 Integer.valueOf(100) 可能指向同一个对象，而 Integer.valueOf(1000) 通常不是同一个对象。这也是为什么不能用 == 判断包装类数值相等。
基本类型使用 == 比较的是值，例如两个 int 都是 1，则 == 为 true。包装类使用 == 时，如果两边都是引用类型，比较的是对象引用是否相同；如果一边是基本类型、一边是包装类，包装类会先拆箱再按基本类型比较。包装类数值比较通常应该使用 equals 或显式拆箱后比较，但 equals 也有类型边界，例如 Integer.valueOf(1).equals(Long.valueOf(1L)) 结果是 false，因为 equals 不只看数值，还要求类型匹配。浮点包装类还要注意 NaN、0.0 和 -0.0 等边界语义，不能把所有比较都简化成普通整数比较。
基本类型在计算密集场景中通常更快，因为不需要对象分配、引用跳转和拆箱调用，也减少 GC 压力。包装类的主要成本来自对象额外内存、可能的堆分配、缓存未命中、频繁拆装箱以及集合中对象分散导致的数据局部性下降。虽然 JIT 可以优化一部分短生命周期包装对象，但集合里的包装对象、跨方法逃逸对象、反射访问对象通常更难完全消除。实际选择时，不应为了所谓统一对象模型而在核心循环、海量指标、排序统计、算法题实现中滥用包装类。
包装类最大的工程风险之一是空指针拆箱。比如一个 Integer 字段来自数据库，值为 null，后续参与 i + 1、i == 0、switch 或赋给 int 时都会触发拆箱，一旦没有提前判空就会抛 NullPointerException。基本类型没有这个问题，但也失去了缺失值的表达能力。因此建模时要先判断字段是否真的允许缺失：计数、状态码、开关这类有明确默认值的字段可考虑基本类型；数据库可空列、外部请求可选字段、缓存未命中状态则更适合包装类或 Optional，并在边界处完成空值处理。
包装类作为对象可以自然参与 Java 序列化、JSON 序列化、反射调用、注解框架、泛型约束和集合协议。反射中基本类型和包装类的 Class 对象也不同，int.class 不等于 Integer.class，方法签名里 int 参数和 Integer 参数是不同的，自动装箱不一定会在所有反射匹配场景中替你完成。泛型边界也只能写 T extends Number 这类引用类型约束，而不能写 T extends int。框架层面还要关注 null：JSON 中字段缺失或 null 映射到 Integer 可以表达缺失，映射到 int 往往只能变成默认 0 或报错，具体取决于框架配置。
因为 Java 泛型的类型参数要求是引用类型，List<int> 不是合法写法，只能写 List<Integer>。这和泛型类型擦除及对象模型有关，集合内部按对象引用存储元素，需要能统一当作 Object 处理。编译器会在 add 时自动装箱，在 get 后需要时自动拆箱，所以表面上可以像处理 int 一样使用，但底层仍然是 Integer 对象。这个限制带来的代价是对象开销、GC 压力和数据局部性下降。如果是大量数值数据，int[] 通常比 List<Integer> 更合适。
Integer a = 127 这种写法会触发自动装箱，通常等价于 Integer.valueOf(127)。Integer.valueOf 会复用缓存范围内的对象，默认 -128 到 127 在缓存中，所以两个 127 可能引用同一个 Integer 对象，== 为 true。128 默认不在缓存范围内，通常会创建不同对象，所以 == 为 false。这里比较的是引用相等而不是数值相等。正确结论不是记住 127 和 128 后写技巧代码，而是任何包装类数值相等判断都不应该依赖 ==，应使用 equals 或明确拆箱。
只要包装类引用为 null，并且代码需要把它转换成基本类型，就会触发拆箱 NPE。常见场景包括 Integer i = null; int x = i，把 Integer 与 int 做 == 比较，参与 i + 1 这样的算术运算，作为 switch 表达式，或者传给需要 int 参数的方法。这个问题隐蔽在于源码里不一定出现 intValue 调用，但编译器会插入。解决方式是在系统边界做 null 校验和默认值处理，或在业务语义上明确字段可空时使用 Objects、Optional、显式分支，而不是让隐式拆箱发生在深层逻辑里。
大多数包装类的 equals 会比较对象类型和内部值，不是跨类型的纯数值比较。例如 Integer.valueOf(1).equals(Long.valueOf(1L)) 是 false，因为一个是 Integer，一个是 Long。Integer.valueOf(1).equals(1) 在自动装箱后比较的是 Integer 与 Integer，结果为 true；但和 Long、Short 这类不同包装类型比较不会因为数值相同就返回 true。浮点包装类还涉及 NaN、0.0、-0.0 等特殊规则。因此回答时要说 equals 比 == 更适合包装类相等判断，但仍然要注意类型边界。
如果字段天然必有值，且主要用于计算、比较、计数、状态判断，优先使用基本类型，因为它更直接、没有 null、性能和内存表现更好。如果需要放入泛型或集合，需要表达数据库 null、请求字段缺失、缓存未命中，或者要与反射、序列化、ORM 框架交互，包装类更合适。一个常见工程策略是：边界层用包装类承接外部不确定性，校验后在核心业务和计算路径中转成基本类型。这样既保留了缺失语义，也降低了核心逻辑的 NPE 风险和装箱成本。
不能绝对说一定慢，但包装类有天然额外成本。它是对象引用，可能需要堆分配，访问时多一层引用间接寻址，对象本身有对象头和对齐开销，频繁创建会增加 GC 压力，参与计算时还可能发生拆箱。现代 JVM 的 JIT 对某些短生命周期、未逃逸的包装对象可以做逃逸分析和标量替换，减少实际分配。但集合中的包装对象、跨方法返回的对象、反射访问对象通常更难被完全优化。所以在性能敏感场景应优先基本类型，在普通业务建模中则先保证语义正确。
int.class 表示基本类型 int 的 Class 对象，Integer.class 表示包装类 Integer 的 Class 对象，它们不是同一个类型。在普通赋值和调用中，编译器可能通过装箱拆箱帮你转换，但反射、方法签名匹配、泛型边界、序列化框架处理时不一定能按直觉自动转换。例如一个方法参数是 int，另一个是 Integer，它们在反射签名中是不同的。框架绑定字段时也会根据 primitive 或 wrapper 决定 null 能否被接受、默认值如何处理。因此在框架边界要明确区分二者。
