java自动装箱编译为valueof()调用而非new，拆箱即xxxvalue()方法调用；缓存适用于boolean、byte、character（\u0000–\u007f）、short、integer（-128~127）、long，float/double不缓存；拆箱null抛npe因intvalue()等方法本身空指针；高频场景应禁用自动装箱以避免gc开销。
Java 的自动装箱（autoboxing）和拆箱（unboxing）不是语法糖的“黑魔法”，而是编译器在字节码层面插入了明确的包装类构造/方法调用，运行时完全依赖 Integer.valueOf()、intValue() 这类标准 API。
自动装箱实际编译成什么字节码
当你写 Integer i = 100;，javac 并不会生成 new Integer(100)，而是调用 Integer.valueOf(100)。这是为了复用缓存对象，避免无谓创建实例。
关键点：
-
Boolean、Byte、Character（\u0000–\u007f）、Short、Integer（-128 到 127）、Long在对应valueOf()方法中都有缓存机制 -
Float.valueOf()和Double.valueOf()不缓存（JDK 9+ 开始明确不保证缓存） - 反编译 class 文件能看到：字节码里是
invokestatic java/lang/Integer.valueOf，不是new指令
拆箱失败时抛出 NullPointerException 的真实原因
拆箱本质是调用包装类的 xxxValue() 方法（如 intValue()），而该方法在接收 null 引用时会直接抛 NullPointerException —— 不是 JVM 特殊处理，就是普通空指针。
立即学习“Java免费学习笔记（深入）”；
典型陷阱场景：
-
Integer i = null; int j = i; // 抛 NPE→ 编译后等价于i.intValue() - 三元运算符隐式拆箱：
boolean b = true; Integer x = b ? 1 : null; int y = x; // 同样 NPE - 集合取值后直接赋基本类型：
List<integer> list = Arrays.asList(1, null, 3); int v = list.get(1); // NPE</integer>
valueOf() 缓存范围可配置但不建议改
Integer 的缓存上限可通过 JVM 参数 -Djava.lang.Integer.IntegerCache.high=200 扩展，但仅影响 valueOf(int)，不影响 new Integer(int)，也不改变 == 比较逻辑。
注意：
- 该参数只在类首次初始化时读取一次，修改需重启 JVM
Integer i1 = 128; Integer i2 = 128; System.out.println(i1 == i2); // false（未命中缓存）Integer i3 = Integer.valueOf(128); Integer i4 = Integer.valueOf(128); System.out.println(i3 == i4); // true（若已设 high=200）
性能与可读性权衡：何时该禁用自动装箱
高频循环或内存敏感场景（如大数据量计算、Android 低内存设备），自动装箱会带来明显开销：对象分配 + GC 压力 + 缓存查找。
实操建议：
- 集合操作优先用原始类型替代方案：如
IntList（Eclipse Collections）、TIntArrayList（Trove）、或 JDK 16+ 的Vector（配合泛型特化） - 避免在 for-each 中对
Collection<integer></integer>做算术：for (Integer x : list) sum += x * 2;→ 改为传统索引遍历 +list.get(i).intValue()显式控制 - 日志或调试打印时，用
String.valueOf(i)替代直接拼接"" + i，避免意外触发装箱
最易被忽略的一点：自动装箱拆箱发生在编译期决定、运行期执行，但它的行为严重依赖包装类源码实现（比如 valueOf 是否缓存、是否 synchronized）。一旦你用反射绕过 public API 或混用不同 JDK 版本，结果可能不一致。
