自动装箱与拆箱是编译期语法糖：装箱调用valueOf()（如Integer.valueOf(100)），拆箱调用xxxValue()（如intValue()）；用于赋值、运算、集合操作等，但易引发NPE、==比较陷阱及性能问题。
Java 中基本类型和包装类之间的自动装箱与拆箱，是编译器在赋值、运算、方法调用等上下文中自动插入的隐式转换，本质是语法糖，不是运行时动态行为。它让代码更简洁，但背后有明确规则和常见陷阱。
装箱和拆箱到底做了什么
装箱（Autoboxing）指把基本类型转成对应包装类对象，例如 int → Integer；拆箱（Unboxing）则相反，例如 Integer → int。这些转换不是靠反射或泛型实现的，而是编译期就确定的：
- 装箱实际调用的是 valueOf() 方法，比如
Integer i = 100;编译后等价于Integer i = Integer.valueOf(100); - 拆箱实际调用的是 xxxValue() 方法，比如
int x = i;编译后等价于int x = i.intValue(); - 只在特定上下文触发：赋值、方法参数传递、算术运算、三元表达式等，不会发生在泛型擦除或反射调用中
哪些地方会悄悄发生装拆箱
日常编码中，这些场景几乎每天都在用，但容易忽略背后的转换：
-
集合操作：ArrayList<Integer> list = new ArrayList<>(); list.add(5); —— 这里的
5被自动装箱；int a = list.get(0);则触发拆箱 -
运算表达式：Integer a = 1; int b = a + 2; ——
a必须先拆箱才能参与加法 -
条件表达式：Integer result = flag ? 1 : null; ——
1装箱为 Integer，但整个表达式类型是 Integer，null 也合法 -
方法重载调用：若存在
void m(int)和void m(Integer)，传入5会优先匹配基本类型版本；而传入new Integer(5)则匹配包装类版本
容易踩坑的关键细节
看似省事，但几个典型问题高频出现：
立即学习“Java免费学习笔记（深入）”；
-
null 拆箱直接抛 NullPointerException：Integer i = null; int x = i; —— 运行时报错，因为
i.intValue()在 null 上调用 - == 比较结果不稳定：Integer a = 127, b = 127; System.out.println(a == b); 输出 true（缓存内复用同一对象）；但 Integer c = 128, d = 128; c == d 就是 false（新建对象）
- 缓存范围有差异：Byte、Short、Integer、Long 默认缓存 -128 到 127；Character 缓存 0–127；Boolean 只有 true/false 两个实例；Float 和 Double 不缓存
- 循环中频繁装拆箱影响性能：for (Integer i : list) sum += i; 每次迭代都拆箱，且若涉及修改（如 i++），还会反复装箱生成新对象，加重 GC 压力
怎么用得更安全高效
不靠记忆，靠习惯：
- 局部计算、高频变量优先用基本类型；需要放进集合、作为泛型参数、或表示“可能为空”时才选包装类
- 从集合取值前先判空再拆箱：
if (obj != null) { int val = obj; }或写成int val = obj != null ? obj : 0; - 避免在 for-each 循环里对包装类做算术运算，可提前解包：
for (Integer item : list) { int v = item; sum += v; } - 理解缓存边界，对关键逻辑中的相等判断统一用
equals()，而不是==
