自动装箱拆箱的关键在于实战避坑：集合操作中频发装箱导致GC压力、null引发NPE、性能敏感场景需绕开装箱、调试时结合字节码与Arthas定位缓存与对象创建问题。
面试中讲自动装箱与拆箱，不能只背定义，关键要让人听出你真用过、调过、踩过坑。重点不是“知道”，而是“用对了”和“避开了哪些雷”。
用在集合操作里——最常见也最容易出错的地方
Java 集合（如 ArrayList
- 比如循环往 ArrayList
里加 10 万次 int i：每次 add(i) 都触发一次 Integer.valueOf(i)，若 i 超出 [-128, 127] 缓存范围，就新建对象，堆内存压力明显上升 - 再比如用 map.get(key) 返回 Long，直接写 if (map.get("count") == 100L) —— 这里先拆箱成 long，但若 map 中 key 不存在，返回 null，就会抛 NullPointerException
用在方法参数和返回值上——隐式转换容易掩盖空指针
接口设计或工具类封装时，如果参数是包装类，调用方传 null 很常见，而自动拆箱会让 NPE 发生在看似安全的等号或算术运算处。
- 例如一个统计方法：public double calcAvg(Integer a, Integer b, Integer c)，内部写 return (a + b + c) / 3.0; —— 若任意一个为 null，+ 号触发拆箱即崩溃
- 实际项目中我们改用 Objects.requireNonNull(a, "a must not be null") 提前校验，或改用 Optional 包装，把空值处理显式化
用在性能敏感模块——比如金融计算、实时日志聚合
这类场景要求低延迟、少 GC。我们曾在线上发现某批处理任务耗时突增，最后定位到是用 Stream
立即学习“Java免费学习笔记（深入）”；
- 优化后改用原始类型数组 + 普通 for 循环，或引入 IntStream 直接操作 int，绕开装箱
- 第三方库如 Eclipse Collections 或 Trove（已停更但仍有项目在用）也常被选来替代 JDK 集合，避免泛型带来的装箱开销
用在调试和排查问题时——看字节码和缓存边界
遇到“两个 Integer 值相等但 == 判断为 false”这类问题，光说“要用 equals”不够；面试官想听你怎么快速定位。
- 我们会用 javap -c 看编译后字节码，确认是否调用了 Integer.valueOf()，再结合缓存范围判断对象复用情况
- 线上用 Arthas 的 watch 命令监控某方法入参中的 Integer 是否频繁 new 出来，辅助判断是否需要重构为基本类型或缓存策略
真正加分的回答，是把语法特性还原成内存动作、GC 行为、异常路径和线上现象——让面试官感觉你写的不是 Demo，而是天天盯着监控和日志的人。
