自动拆装箱是编译期语法糖，本质为插入valueof()和xxxvalue()调用；带来对象创建、缓存边界及空指针等隐性成本，需注意性能与安全风险。
自动拆装箱是编译期完成的语法糖，本质是编译器自动插入 valueOf() 和 xxxValue() 方法调用，不是运行时动态行为。它带来便利的同时，也引入了对象创建、缓存边界、空指针等隐性成本。
装箱：valueOf() 调用 + 缓存机制
自动装箱（如 Integer i = 100;）会被编译为 Integer i = Integer.valueOf(100);。这个方法内部有缓存优化：
- -128 到 127 范围内复用对象：IntegerCache 预先创建并缓存这些值，多次装箱返回同一对象引用；
-
范围外每次新建对象：比如
Integer i = 2000;每次都 new 出新 Integer 实例； - 其他包装类也有类似缓存（如 Byte、Short、Character），但 Long 和 Double 的缓存默认仅限 -128~127，且不可扩展；Boolean 缓存 true/false 两个实例。
拆箱：xxxValue() 调用 + 空指针风险
自动拆箱（如 int n = i;）等价于 int n = i.intValue();。关键点在于：
- 如果
i是 null，调用intValue()会立即抛出 NullPointerException； - 该异常不是发生在赋值语句本身，而是发生在编译器插入的方法调用上，容易被忽略；
- 拆箱开销本身很小，但一旦出现在循环或高频路径中，叠加装箱产生的对象，就会放大 GC 压力。
性能影响主要来自三方面
看似一行代码，背后可能触发对象分配、内存访问、GC 回收：
-
频繁装箱 → 内存与 GC 开销：在 for 循环里反复写
list.add(i)（i 是 int），每次都会装箱成新 Integer，尤其超出缓存范围时，大量短命对象加重 Young GC； -
隐式装箱/拆箱链式发生：比如
Integer a = 100; Integer b = 200; Integer sum = a + b;，这里 a、b 先拆箱为 int，相加后再装箱为 Integer，一来一回两次对象操作； -
缓存失效导致误判相等性：用
==比较两个装箱结果，-128~127 内可能为 true，范围外几乎总为 false，易引发逻辑错误。
实际开发中的规避建议
不是否定自动拆装箱，而是明确知道它在哪“悄悄干活”：
- 集合操作中，若数据量大、循环密集，优先考虑 原生类型专用库（如 Eclipse Collections、Trove、FastUtil）；
- 避免在循环体内做
Integer运算，改用基本类型变量暂存； - 从集合或方法返回获取包装类型时，先判空再拆箱，或用
Objects.requireNonNull(i).intValue()显式表达意图； - 需要比较值相等时，统一用
.equals()或拆箱后用==，不依赖==判包装类引用。
