自动装箱是编译器将基本类型转为包装类时调用valueOf()方法，拆箱则调用xxxValue()方法；两者均在编译期确定、可追踪，涉及缓存、null风险及性能开销。
自动装箱就是编译器悄悄调用 Integer.valueOf()，不是语法糖的幻觉
自动装箱不是“类型自动变对象”，而是编译器在编译期硬生生把 int i = 10; Integer obj = i; 改写成 Integer obj = Integer.valueOf(i);。你用 javap -c 反编译就能看到字节码里明确调用了 invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;。这说明它本质是确定的、可追踪的转换逻辑，不是运行时动态行为。
- 所有包装类都走
valueOf()：比如Boolean.valueOf(true)、Double.valueOf(3.14) -
Integer.valueOf(int)有缓存优化：-128 到 127 的整数会复用已有对象，超出范围则新建实例 - 别用
new Integer(10)：它绕过缓存，且从 Java 9 起已被标记为@Deprecated(forRemoval = true)
自动拆箱本质是调用 intValue() 类方法，null 时直接抛 NullPointerException
当你写 int j = integerObj;，编译器生成的字节码是 integerObj.intValue()。这意味着只要 integerObj == null，运行时就会在调用 intValue() 前触发空指针异常——不是在比较或赋值时“突然”出错，而是在拆箱那一步就崩了。
- 常见踩坑场景：
ArrayList→ 直接 NPElist = new ArrayList(); list.add(null); int x = list.get(0); - 条件表达式也隐含拆箱：
int result = flag ? boxedA : boxedB;中任一为null就炸 - 用
==比较两个Integer时：如果值在缓存范围内（如Integer a = 100, b = 100;），a == b可能为true；但Integer c = 200, d = 200;时c == d是false（因为新建对象）；若其中一个是null，==会先尝试拆箱，再报 NPE
哪些地方会静默触发装箱/拆箱？看编译器是否需要类型对齐
装箱和拆箱不是“写出来才发生”，而是编译器为了满足类型契约，在以下三类上下文中自动插入转换代码：
- 赋值：基本类型 → 包装类（装箱），包装类 → 基本类型（拆箱）
-
方法调用：传
int给void foo(Integer x)→ 装箱；传Integer给void bar(int y)→ 拆箱 -
运算与比较：
Integer a = 5; int b = a + 3;→ 先拆箱a.intValue()，再算加法；if (a == 5)→a拆箱后与int比较
注意：泛型擦除后集合实际存的是 Object，所以 list.add(1) 是装箱，int x = list.get(0) 是拆箱 —— 这正是 Java 5 引入该机制最直接的驱动力。
性能和安全风险：高频装箱=高频对象创建，null 拆箱=隐形炸弹
装箱意味着堆上分配对象（哪怕缓存复用也有哈希查找开销），拆箱意味着一次方法调用+潜在空指针。在循环、高频计算或底层工具类中，它们可能成为瓶颈或故障源。
- 避免在
for循环里反复装箱：for (int i = 0; i → 百万次Integer.valueOf(i) - 用原始类型集合库替代（如
IntListfrom Eclipse Collections 或TIntArrayListfrom Trove）可
彻底规避
- 对外部输入（如 JSON 解析、DB 查询结果）拿到的包装类型，务必先判空再拆箱：
if (obj != null) value = obj.intValue(); - 单元测试要覆盖
null分支：尤其涉及 Optional、Map.get()、数据库字段可能为空的场景
真正危险的从来不是“不知道有这机制”，而是以为它像数学转换一样安全无副作用 —— 它带着对象生命周期、缓存边界和空值语义，每一步都得当真。
