自动装箱是编译器将基本类型转为包装类（如int→integer），调用valueof()；拆箱反之，调用xxxvalue()。雷区：-128~127缓存导致==判等结果不一致；null拆箱抛npe；循环中频繁装箱引发性能问题。
Java 中自动装箱与拆箱看似简单，但大厂面试常深挖细节、边界和性能陷阱。关键不是背定义，而是讲清“什么时候发生、为什么危险、怎么避坑”。
自动装箱/拆箱到底在干啥？
自动装箱（Autoboxing）是编译器把基本类型（如 int）自动转成对应包装类（如 Integer）；拆箱（Unboxing）反之。本质是语法糖，底层调用的是 Integer.valueOf() 和 intValue() 等方法。
例如：
Integer a = 100; // 装箱：等价于 Integer a = Integer.valueOf(100);
int b = a; // 拆箱：等价于 int b = a.intValue();
高频雷区：缓存机制与 == 判等陷阱
Integer.valueOf(int) 在 -128 到 127 范围内会复用缓存对象，超出则每次新建。这直接导致：
- Integer a = 127, b = 127; System.out.println(a == b); // true（同引用）
- Integer c = 128, d = 128; System.out.println(c == d); // false（不同对象）
- 但用 equals() 或与基本类型比较（a == 127）始终安全——因为后者会触发自动拆箱
面试官爱问：“为什么 128 == 128 是 false？” 答案要落到缓存范围 + 对象引用比较上，不能只说“包装类用 == 不安全”。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
空指针风险：拆箱时最隐蔽的崩溃点
当一个包装类引用为 null，却参与拆箱运算，立刻抛 NullPointerException：
Integer x = null;
int y = x; // 运行时报错！
if (x == 10) { ... } // 同样报错！因为先拆箱再比较
常见于：从 Map/JSON 取值后未判空就直接算术运算或条件判断。应对策略：
- 优先用基本类型接收明确非空值（如方法参数、数据库映射字段）
- 包装类型仅用于可能为 null 的场景（如 Optional、Map.get()），且后续操作前显式判空或用 Objects.equals()
- 必要时用 Optional.ofNullable(x).orElse(0) 安全解包
性能隐患：循环中别让装箱“悄悄爆炸”
在高频循环里频繁装箱（比如 for (int i = 0; i ，其中 list 是 ArrayList
优化思路：
- 能用基本类型集合库（如 fastutil、trove 或 JDK 16+ 的 ArrayDeque
替代方案）就不用包装类 - 批量操作优先用 Arrays.stream(ints).boxed().collect(...) 显式控制时机，而非隐式触发
- 避免在日志或 toString() 中无意触发装箱（如 log.info("value=" + integerObj)）
不复杂但容易忽略——真正拉开差距的，是你能否从字节码层面解释 valueOf 缓存逻辑，或现场写出一段会 NPE 的拆箱代码并修复它。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
