自动装箱与拆箱是编译器在编译期自动插入valueOf()和xxxValue()方法调用的机制，本质是编译器+运行时协作：valueOf()有-128~127缓存，null拆箱抛NPE，==比较易因缓存失效导致false。
回答自动装箱与拆箱，关键不是背定义，而是讲清“为什么存在”“怎么用”“哪里踩坑”，再配上一个真实场景的代码分析。面试官想看的是你是否真正理解 JVM 在底层做了什么，以及有没有线上排错经验。
说清楚本质：不是语法糖，是编译器+运行时协作的结果
自动装箱（autoboxing）指基本类型 → 对应包装类（如 int → Integer），拆箱（unboxing）反之。但要注意：
- 这是编译期插入的隐式调用，比如
Integer i = 100;实际编译为Integer i = Integer.valueOf(100); - valueOf() 有缓存机制：-128 到 127 范围内的 Integer、Short、Byte、Character 和部分 Boolean/Long 会复用缓存对象；超出范围每次 new 新对象
- 拆箱本质是调用
xxxValue()方法（如intValue()），若对象为 null，运行时直接抛 NullPointerException
必举一个让人记住的反例：== 判等陷阱
这是高频扣分点。光说“用 equals”不够，要现场对比两段代码：
错误写法：
Integer a = 128, b = 128;<br>System.out.println(a == b); // false —— 因为超出缓存，两个不同对象
正确写法：
Integer a = 128, b = 128;<br>System.out.println(a.equals(b)); // true<br>// 或者都用基本类型比较：<br>int x = a, y = b;<br>System.out.println(x == y); // true
顺便提一句：推荐在判等时优先用 Objects.equals(a, b)，它天然处理 null 安全和类型转换。
结合真实问题：空指针和性能隐患怎么暴露的？
不要只讲理论。可以说一个你（或团队）遇到的典型 case：
-
Map.get() 返回 null 后直接拆箱：
int value = map.get("key");—— 如果 key 不存在，get 返回 null，拆箱瞬间 NPE -
循环中频繁装箱导致 GC 压力：比如
for (int i = 0; i （list 是ArrayList），每次 add 都触发装箱，可改用原生数组或 IntStream 优化 -
泛型擦除 + 拆箱组合出的诡异行为：比如方法接收
Number，传入Integer没问题，但传null进去再拆成 int 就崩了
收尾补一句深度认知：装箱/拆箱是“便利性”和“安全性”的权衡
Java 设计它是为了让基本类型能进集合、当泛型实参、参与多态——但代价是隐藏了对象创建、方法调用和空值风险。所以高手不是不用，而是清楚每行代码背后发生了几次装箱/拆箱，尤其在性能敏感或 null 可能出现的路径上主动防御。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
