自动装箱是编译器将基本类型（如int）隐式转为包装类对象（如integer），调用valueof()；拆箱则相反，调用xxxvalue()方法；发生在赋值、方法传参、运算等场景。
Java 包装类面试题核心就三点：理解自动装箱/拆箱机制、掌握缓存范围（尤其 Integer）、清楚 == 与 equals 的区别。答错往往不是不会，而是忽略细节或混淆场景。
自动装箱和拆箱是怎么回事？什么时候发生？
自动装箱是编译器把基本类型转成对应包装类对象（如 int → Integer），拆箱则相反（Integer → int）。它们发生在赋值、方法传参、运算等上下文中，由编译器在编译期插入隐式调用（比如 Integer.valueOf() 和 xxx.intValue()）。
- 赋值时：
Integer i = 100;→ 自动装箱；int j = i;→ 自动拆箱 - 方法调用：传
int给接收Integer的参数，或反之 - 运算表达式：如
Integer a = 1; Integer b = 2; int sum = a + b;→ a、b 先拆箱再相加
为什么 Integer.valueOf(127) == Integer.valueOf(127) 是 true，但 valueOf(128) == valueOf(128) 是 false？
因为 Integer 缓存了 -128 到 127 范围内的对象（可配置，但默认如此）。调用 valueOf() 时，这个范围内的值直接返回缓存对象，所以 == 比较的是同一个引用；超出范围则每次新建对象，== 就是 false。
-
Integer a = 127, b = 127;→a == b为 true（都在缓存池） -
Integer c = 128, d = 128;→c == d为 false（各自 new 出来） - 其他包装类只有 Boolean、Byte、Character（0~127）、Short、Long 有缓存，但范围不同；Float 和 Double 没有缓存
== 和 equals 在包装类里怎么选？有什么坑？
用 == 容易出错，优先用 equals。== 比较的是引用是否相同（即是不是同一个对象），而 equals 比较的是数值是否相等（重写了 Object 的 equals 方法）。
- 两个
Integer对象用 ==：只在缓存范围内且值相同时才可靠 - 混合类型比较（如
Integer == int）会触发自动拆箱，此时 == 实际比较的是数值，不会空指针（除非左边为 null） - 最危险的是
null == Integer或Integer.equals(null)：前者安全（结果 false），后者会抛 NPE；所以推荐用Objects.equals(a, b)
包装类有哪些典型陷阱？怎么避免？
常见问题集中在空指针、缓存误用、性能开销三方面。
-
空指针异常：拆箱时如果包装类变量为 null，会直接报 NPE（如
Integer i = null; int x = i;） - 缓存误解：以为所有 Integer 都缓存，或误用 == 判断任意两个包装类是否“值相等”
-
性能隐患：循环中频繁装箱（如
list.add(i)，i 是 int）会创建大量临时对象；高频场景考虑用原生数组或专门工具类（如 Trove、Eclipse Collections） - 最佳实践：判空再拆箱；比较用 equals 或 Objects.equals；集合中存基本类型需求大时评估是否改用原始类型集合
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
