自动装箱发生在编译期，如int赋值给Integer变量或传参时插入valueOf()调用；超出-128~127范围时新建对象，==比较易出错；null拆箱抛NullPointerException；泛型集合必须装箱，影响性能。
自动装箱到底什么时候发生
当你把一个 int 值赋给 Integer 变量，或者传给需要 Integer 的方法参数时，编译器会悄悄插入 Integer.valueOf() 调用。这不是运行时“智能识别”，而是编译期的语法糖。
常见错误现象：以为 Integer a = 1000; Integer b = 1000; a == b 是 true —— 实际是 false，因为超出缓存范围（-128 到 127），每次调用 valueOf() 都新建对象。
- 只发生在赋值、方法调用、泛型集合添加等明确类型转换场景，比如
list.add(42)→ 自动装箱为Integer - 算术运算如
Integer a = 1; int b = a + 2;会先拆箱再计算，不创建新对象 - 构造器写法
new Integer(42)不触发装箱机制，且已废弃，别用
拆箱失败的典型报错和原因
NullPointerException 是最常踩的坑：对值为 null 的 Integer 执行拆箱操作时，JVM 会调用 intValue()，而空引用直接抛异常。
常见错误现象：Integer status = getStatusFromDB(); int code = status == null ? -1 : status; —— 这里 status 为 null 时，status 右侧的隐式拆箱就崩了。
立即学习“Java免费学习笔记（深入）”；
- 所有涉及
==、!=比较两个Integer时，要意识到：如果其中一个是null，另一侧哪怕值合法，也可能在比较前就拆箱失败 - 三元表达式里混用包装类和基本类型，容易漏掉
null检查，建议显式写成status != null ? status.intValue() : -1 - 使用
Optional<integer></integer>代替可能为null的Integer，能从源头避免拆箱风险
valueOf() 缓存策略的实际影响
Integer.valueOf(int) 在 -128 到 127 范围内返回缓存对象，超出则新建实例。这个缓存是 JVM 规范允许但不强制的实现细节，OpenJDK 和 HotSpot 都做了，但不能依赖它做对象身份判断。
使用场景：高频创建小整数（如状态码、HTTP 状态）时，缓存能减少 GC 压力；但若误拿 == 判断值相等，就会在边界外出问题。
- 永远用
.equals()或Objects.equals(a, b)比较两个Integer的值，不要用== - 自定义缓存范围可通过 JVM 参数
-XX:AutoBoxCacheMax=200扩展（仅限Integer），但线上环境慎改，不同 JDK 版本行为可能不一致 -
Long.valueOf()、Short.valueOf()也有缓存，但只有Integer支持该 JVM 参数调节
泛型集合里装基本类型必须靠装箱
Java 泛型不支持基本类型，所以 List<int></int> 合法语法都不存在。你写 List<integer></integer>，往里 add int 值，就得走自动装箱；取出来用时又得拆箱。
性能影响：高频增删小整数（比如计数器循环）会导致大量临时 Integer 对象，GC 压力上升，甚至比预想慢几倍。
- 大数据量场景下，优先考虑
int[]、IntArrayList（来自 fastutil 或 eclipse-collections）等专门结构 - Stream 操作如
list.stream().mapToInt(Integer::intValue).sum()能避免中间装箱，但要注意mapToInt返回的是IntStream，后续操作受限 - 不要为了“统一类型”把局部
int变量硬改成Integer，徒增开销
缓存范围、null 拆箱、泛型约束这三点交叉在一起，最容易写出看似能跑、一压测就崩的代码。尤其注意日志打印或 JSON 序列化时，不经意间触发了隐式拆箱——那里的 null 往往比业务逻辑里更难察觉。
