Java面试考察基本类型与包装类重在实战坑点、源码理解及场景选型：默认值差异易致NPE；==比较受缓存机制影响；装箱拆箱有性能与空指针风险；选型需依计算密集度、框架集成、契约语义等综合判断。
Java进阶面试里，基本类型与包装类绝不是“背个区别表”就能过关的。考官真正想看的是你是否踩过坑、读过源码、理解JVM行为，以及能否在真实场景中做合理选型。
一、默认值差异背后的真实风险
基本类型默认是 0 / false，包装类默认是 null。这个看似简单的区别，在数据库交互、RPC调用、JSON反序列化中极易引发空指针异常。
- POJO字段用
int接收数据库可能为NULL的列 → 查询时自动拆箱抛NullPointerException - 前端传参缺失某数字字段，Jackson 默认反序列化为
null→ 若后端用int接收会直接报错（编译不通过），必须用Integer - Map.get(key) 返回
null，若直接赋给基本类型变量（如int v = map.get("x")）→ 拆箱时崩溃
二、“==”比较陷阱与缓存机制源码级理解
包装类用 == 判断相等，结果高度依赖 valueOf() 的缓存策略——这不是约定，是 IntegerCache、LongCache 等静态内部类明确定义的行为。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
Integer a = 127; Integer b = 127;→a == b为 true（-128 ~ 127 缓存命中） -
Integer c = 128; Integer d = 128;→c == d为 false（超出缓存范围，新建对象） -
new Integer(127) == new Integer(127)永远是 false（堆上两个不同对象） -
Boolean.TRUE == Boolean.TRUE总是 true（Boolean 只有 true/false 两个实例，全部缓存）
三、自动装箱/拆箱不是“免费午餐”，而是隐式性能与安全代价
编译器帮你补了 valueOf() 和 xxxValue()，但每次调用都意味着对象创建、内存分配或空指针检查——尤其在循环或高频路径中会被放大。
- 循环里写
list.add(i)（i 是 int，list 是List）→ 每次都触发装箱，产生大量短生命周期对象，加重GC压力 -
Integer x = null; int y = x;→ 拆箱瞬间抛NullPointerException，且堆栈不指向业务逻辑行，排查困难 - 泛型擦除后，集合实际存储的是
Object，运行时无法避免装箱；而int[]是连续内存块，ArrayList是对象引用数组，空间开销差数倍
四、选型决策要结合场景，不是“统一用包装类”或“全用基本类型”
没有银弹。关键看语义、性能边界和上下文约束：
- 计算密集型场景（如算法、数学运算、批量处理）→ 优先用基本类型，避免无谓装箱和GC干扰
-
面向接口/框架集成（MyBatis返回、Spring MVC参数、Dubbo响应体）→ 必须用包装类，保障
null可表达性 - DTO/VO/POJO 层属性 → 阿里规范强制要求包装类型，本质是契约层需明确区分“未传值”和“值为零”
- 局部临时变量/循环计数器 → 基本类型更自然、更安全、更高效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
