自动装箱和拆箱在赋值、方法传参、运算表达式中触发；==比较包装类易因缓存产生误导，应使用Objects.equals()；null拆箱会抛NPE，需判空或用Optional；高频装拆箱影响性能。
什么时候会触发自动装箱和拆箱
Java在编译期对 Integer、Boolean 等包装类与对应基本类型（如 int、boolean）之间的赋值、方法传参、运算表达式做了隐式转换。只要上下文需要基本类型却给了包装类，或反之，就会触发自动装箱（boxing）或拆箱（unboxing）。
常见触发场景包括：
- 将
int赋值给Integer变量（装箱） - 将
Integer用在+、==、if条件中（拆箱） - 向泛型集合（如
ArrayList）添加int值（装箱） - 从集合取元素并参与算术运算（拆箱）
== 比较包装类时的陷阱
== 对包装类比较的是引用，不是值；但 Java 对部分小整数做了缓存优化，导致某些情况“碰巧”为 true，极易误导。
例如：
立即学习“Java免费学习笔记（深入）”；
Integer a = 100; Integer b = 100; System.out.println(a == b); // true —— 因为 -128 ~ 127 在 IntegerCache 中复用对象 Integer c = 200; Integer d = 200; System.out.println(c == d); // false —— 超出缓存范围，新建对象
正确做法永远是用 .equals() 比较值，但注意 null 安全：
- 用
Objects.equals(a, b)最稳妥 - 避免
a.equals(b)当a可能为null -
==仅适合判断是否为同一对象（极少场景）
拆箱时的 NullPointerException 风险
当一个包装类引用为 null，又参与需要基本类型的运算（如加减、条件判断），JVM 会尝试调用 .intValue() 等方法，从而抛出 NullPointerException。
典型出错代码：
Integer count = null; int result = count + 1; // 抛出 NullPointerException
这类问题常出现在数据库查询返回 null 的字段、JSON 解析缺失字段、或 Optional 未妥善处理时。预防方式包括：
- 显式判空：
if (count != null) { ... } - 使用
Optional.ofNullable(count).orElse(0) - 用
Objects.requireNonNullElse(count, 0)（Java 9+） - 避免在业务逻辑中过度依赖自动拆箱
性能与内存开销不可忽视
每次装箱都新建对象，拆箱涉及方法调用；高频操作（如循环内装箱/拆箱）会显著增加 GC 压力和 CPU 开销。
反模式示例：
long sum = 0;
for (int i = 0; i < 1000000; i++) {
Integer x = i; // 每次循环都 new Integer(i)
sum += x; // 每次都拆箱
}
应改为直接使用基本类型：
long sum = 0;
for (int i = 0; i < 1000000; i++) {
sum += i; // 零开销
}
其他注意事项：
-
Boolean、Character也有缓存（Character是 0~127），但Long、Double默认不缓存（除-128~127的Long在部分 JDK 版本有例外） - 自定义缓存行为可通过 JVM 参数调整（如
-XX:AutoBoxCacheMax=200），但不推荐线上随意改动 - 泛型容器必须用包装类，这是语言限制，无法绕过；但可尽量减少中间装箱步骤（如用
IntStream替代Stream）
Integer i = 42; 这种简单赋值里，而藏在嵌套泛型、流式计算、或跨层调用后被层层拆箱的那一刻。 
