自动装箱拆箱是Java为弥合基本类型与引用类型鸿沟而设的机制，使ArrayList等泛型集合可操作int等基本类型；但引发==比较陷阱、缓存边界问题、null拆箱NPE及性能开销。
Java里自动装箱和拆箱不是“语法糖”那么简单，而是为了在泛型、集合、方法重载等场景下弥合基本类型和引用类型的鸿沟——没有它，ArrayList根本无法编译，Integer.valueOf(42)就得手动写满整个项目。
为什么ArrayList不能直接存int
泛型在编译期被擦除，运行时只剩Object，而int不是Object子类，无法参与类型擦除后的统一处理。所以JVM强制要求集合元素必须是引用类型。
-
ArrayList编译失败：泛型不支持基本类型 -
ArrayList合法，但每次add(42)会触发自动装箱 → 调用Integer.valueOf(42) -
int x = list.get(0);触发自动拆箱 → 调用intValue() - 注意：
Integer.valueOf()对-128到127范围有缓存，超出范围会新建对象，影响==判断结果
==比较失效的典型场景
自动装箱让==语义变得危险：它比较的是引用（对象地址），不是数值。哪怕两个Integer值相同，也可能不相等。
Integer a = 128; Integer b = 128; System.out.println(a == b); // false —— 不在缓存范围内，是两个不同对象 Integer c = 100; Integer d = 100; System.out.println(c == d); // true —— 缓存复用，指向同一对象 System.out.println(a.equals(b)); // true —— 正确的值比较方式
- 永远别用
==比较包装类，除非你明确知道它们来自缓存且值在-128~127 -
Objects.equals(a, b)更安全，能同时处理null - 方法参数重载时，
void foo(int x)和void foo(Integer x)可能因自动拆箱/装箱导致调用歧义
性能损耗在哪？什么时候该避免
每次装箱都新建对象（缓存外）、每次拆箱都调用方法，堆内存和GC压力真实存在，尤其在高频循环中。
- 高频场景如：
for (int i : list) { ... }对ArrayList遍历时，每次迭代都发生拆箱 - 替代方案：原始类型集合库（如Agrona的
IntArrayList，或Guava的Ints.asList()） - Stream操作中，
list.stream().mapToInt(Integer::intValue)可提前转为原始流，避免中间装箱 - 自定义方法参数尽量用基本类型，而非包装类，除非
需要表达
null语义
自动装箱拆箱最隐蔽的问题不是功能错误，而是缓存边界和null引发的NullPointerException——比如Integer x = null; int y = x;会在拆箱时直接抛出异常，这个空指针往往离赋值点很远，排查成本高。
