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免费学习笔记（深入）”；
典型陷阱场景：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
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 版本，结果可能不一致。
