自动装箱与拆箱本质是编译器在编译期插入的隐式方法调用：装箱转为Integer.valueOf()（含-128~127缓存），拆箱转为intValue()；触发于赋值、方法调用、运算等类型不匹配场景；null拆箱抛NPE，==比较受缓存影响。
自动装箱与拆箱的本质不是语法糖，而是编译器的隐式转换
很多候选人一上来就说“自动装箱是编译器加的语法糖”，这没错，但面试官真正想听的是：它在字节码层面做了什么、什么时候触发、为什么会有性能和逻辑陷阱。Java 编译器（javac）会在编译期将 Integer i = 100; 翻译成 Integer.valueOf(100)，把 int j = i; 翻译成 i.intValue()。关键点在于：valueOf() 方法有缓存机制，而 new Integer() 没有——这是绝大多数空指针、== 判断出错、性能抖动的根源。
缓存范围陷阱：-128 到 127 是默认安全区，但可被打破
Integer.valueOf(int) 默认缓存 -128 ~ 127 的 Integer 实例，超出范围会新建对象。这意味着：
-
Integer a = 100; Integer b = 100;→a == b为 true（同一缓存对象） -
Integer c = 200; Integer d = 200;→c == d为 false（两个不同对象） - 这个范围可通过 JVM 参数
-Djava.lang.Integer.IntegerCache.high=500扩大，但不推荐；JDK9+ 还支持通过系统属性java.lang.Integer.IntegerCache.low调整下界 - 其他包装类也有类似机制：Boolean 全部缓存，Byte/Short/Character 缓存全部取值范围，Long/Double 只缓存 -128~127（但 JDK 规范未强制，实际实现基本一致）
空指针风险：拆箱时最隐蔽的崩溃点
自动拆箱本质是调用 xxxValue() 方法，一旦包装类引用为 null，就会抛 NullPointerException。常见高危场景：
-
Integer i = null; int j = i;→ 直接 NPE（编译通过，运行爆炸） - 集合中存了 null 的 Integer，遍历时用增强 for 或流操作做算术运算（如
list.stream().mapToInt(x -> x * 2).sum()） - 数据库查询返回的 nullable 字段映射为 Integer，未判空就参与计算或比较
- 解决办法不是“永远用 equals”，而是：明确判空、优先用 Optional 包装、数据库字段非空约束 + 对应类型用 int（非 Integer）
性能与设计误用：别让装箱成为高频操作的瓶颈
频繁装箱拆箱在循环或高频方法中会造成显著 GC 压力和 CPU 开销。例如：
立即学习“Java免费学习笔记（深入）”；
for (int i = 0; i （list 是 <code>ArrayList<integer></integer>）→ 每次 add 都触发一次装箱，生成 10 万个临时 Integer 对象- 用
Map<integer string></integer>存大量小整数键 → 键对象本身开销可能超过值数据 - 替代方案：原始类型集合库（如 Eclipse Collections、Trove、FastUtil）、或改用数组+索引逻辑、或确认是否真需要泛型抽象（比如用 int[] + 工具类封装）
- 注意：Stream API 中
IntStream是原始类型流，stream().mapToInt(...)能避免中间装箱，比stream().map(...).mapToInt(...)高效得多
面试高分回答的关键：把“知道”变成“踩过坑”的表达
不要只背定义。可以这样组织答案：
- 先说现象：“自动装箱是编译器将基本类型和包装类之间隐式转换的过程，背后调用的是 valueOf 和 xxxValue 方法”
- 立刻跟陷阱：“但它不是无害的——缓存机制导致 == 判断不可靠，null 拆箱直接 NPE，高频装箱引发 GC”
- 补一个真实细节：“我线上遇到过 MyBatis 返回 Integer 字段为 null，前端传参没校验，后端直接参与减法运算，结果 500 报错。后来统一加了 @Valid 和自定义参数解析器拦截 null Integer”
- 最后收在设计意识：“现在新项目里，能用 int 就不用 Integer，DTO 里非空字段全用基本类型，包装类只用于泛型、反射、可空语义明确的场景”
