自动装箱发生在哪些地方
自动装箱不是“运行时偷偷转换”，而是编译器在编译期就插入了 Integer.valueOf()、Boolean.valueOf() 这类调用。只要类型匹配且上下文需要包装类，就会触发——比如赋值给包装类型变量、作为泛型参数传入、放进集合（ArrayList<integer></integer>）、或者调用接收包装类的方法。
常见错误现象：NullPointerException 在看似安全的算术操作中爆发，比如 Integer a = null; int b = a + 1; —— 这里解包时才会抛异常，不是装箱时。
- 只有
byte、short、char、int、long、float、double、boolean八种基本类型有对应自动装箱行为 -
char装箱为Character，不是String；别指望"" + 'a'触发装箱 - 方法重载时，自动装箱可能引发歧义：如果同时存在
foo(int)和foo(Integer)，传5会优先选int版本（不触发装箱）
Integer.valueOf() 缓存机制怎么影响结果
装箱不是每次都新建对象。Integer.valueOf(int) 对 -128 到 127 范围内的值返回缓存实例，超出范围则 new 出新对象。这意味着 == 比较在小整数上可能为 true，大整数上一定为 false，哪怕值相等。
典型陷阱：Integer a = 100; Integer b = 100; System.out.println(a == b); // true；但换成 1000 就是 false。
立即学习“Java免费学习笔记（深入）”；
- 缓存范围可通过 JVM 参数
-XX:AutoBoxCacheMax=200扩展（仅对Integer有效） -
Boolean.valueOf()总是返回缓存对象（只有TRUE/FALSE两个） -
Double.valueOf()和Float.valueOf()不做缓存（IEEE 754 浮点表示太稀疏）
什么时候该避免自动装箱
性能敏感场景（如循环内高频计算）、容器遍历、或明确需要空值语义时，自动装箱反而是负担。它带来对象创建开销、GC 压力，还掩盖了 null 风险。
使用场景判断：如果你只是做数学运算、数组索引、位操作，坚持用基本类型；如果要放进 Map<k v></k> 或需要表达“未设置”状态，才用包装类。
- 不要写
for (Integer i = 0; i —— <code>i++每次都拆箱+装箱 - 避免在
OptionalInt可用时还用Optional<integer></integer> - 用
Objects.equals(a, b)替代a.equals(b)，防止a为null时 NPE
泛型和自动装箱的冲突点
泛型擦除后，JVM 看不到类型参数，所以 List<integer></integer> 实际存储的是 Object 数组。每次取值都要强制转型 + 解包，而编译器插入的装箱代码又让写入变慢。这不是语法糖的错，是泛型设计与原始类型割裂导致的必然代价。
错误现象：把 int[] 直接传给期望 List<integer></integer> 的方法，编译失败——数组不是集合，自动装箱不跨这种边界。
- 不要试图用
Arrays.asList(1, 2, 3)得到可变的List<integer></integer>：它返回的是固定大小的包装视图，且底层是Integer[]，不是int[] -
Stream.of(1, 2, 3)生成的是Stream<integer></integer>，因为可变参数接受的是Integer...，不是int... - 用
IntStream.range(0, n)替代Stream.iterate(0, i -> i + 1).limit(n)，避免无谓装箱
自动装箱看着省事，但它的生命周期横跨编译、运行、GC 多个阶段。最易被忽略的是：它让 null 静默混入数值流，而解包那一刻才爆炸——这个时机往往远离问题源头。
