自动装箱与拆箱本质是对象创建与方法调用，-128~127间复用缓存，超范围则新建对象；拆箱遇null抛npe；高频场景应优先使用基本类型、原始函数接口或专用集合以避免gc压力和空指针风险。
理解自动装箱与拆箱，关键不是记住“编译器插了valueOf或xxxValue”，而是看清它在运行时真实发生的对象行为——尤其是何时创建新对象、何时复用缓存、何时触发空指针或隐式开销。高性能代码的核心，是避免在高频路径上无意识地制造对象和方法调用。
装箱本质是对象创建，不是零成本赋值
写 Integer i = 100; 看似简单，背后是调用 Integer.valueOf(100)。这个方法有缓存逻辑：
- -128 到 127 范围内：返回缓存池中已有对象（轻量，推荐）
- 超出该范围（如 Integer j = 300;）：每次调用都 new Integer(300)，产生新对象
- 缓存范围可被 JVM 参数调整（-XX:AutoBoxCacheMax=200），但默认仅限 -128~127
在循环、Stream 处理或高频计算中反复装箱大整数（如计数器 >127），会快速堆积临时对象，增加 GC 压力。
拆箱看似安全，实则暗藏空指针风险
写 int n = wrapper; 时，编译器自动补上 wrapper.intValue() ——但若 wrapper 为 null，运行时直接抛 NullPointerException，且堆栈不指向你写的那行赋值语句，而是指向底层 intValue() 调用。
- 常见陷阱场景：从 Map/集合取值后未判空就拆箱（如 map.get("key") 返回 null，再赋给 int）
- Stream 中使用 mapToInt() 可规避（它内部处理 null 安全），但 map(x -> x.getValue()) 后直接 .sum() 就可能崩
- 建议：对可能为 null 的包装类型变量，显式判空再拆箱，或改用 Optional
集合与泛型是装箱最密集的重灾区
ArrayList
- 避免用 List
存大量整数做数学运算；改用第三方库如 Eclipse Collections 的 IntArrayList，或原生数组 int[] - Map
查找 key 时，若传入 int 类型参数（如 map.get(i)），会自动装箱成 Integer —— 高频调用下可考虑预缓存常用 Integer 对象（如 0~100） - for-each 遍历 List
：每次 Integer item : list 都触发拆箱；若后续只读基本值，用传统 for + get(i) 并缓存 list.size() 更可控
性能敏感场景，优先用基本类型原语
不是所有地方都需要包装类。明确以下原则可大幅减少隐式开销：
- 局部计算变量：坚持用 int、long、double，而非 Integer/Long/Double
- 方法参数/返回值：若无需 null 表达“缺失”，就别用包装类；必要时用注解如 @NonNull + 显式判空
- 替代方案：IntFunction、ToIntFunction、IntSupplier 等原始类型函数式接口，比 Function
更高效 - 序列化/网络传输：包装类多一层对象封装，JSON 库（如 Jackson）对 int 和 Integer 序列化结果一致，但运行时内存占用不同
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
