自动装箱带来三类开销：对象分配与GC压力、缓存查找与边界判断、间接访问与CPU指令增多；循环中反复add/get、流式操作mapToInt等最易暴露性能问题。
Java 集合框架（如 ArrayList、HashMap）只能存储对象，不能直接存基本类型（int、boolean 等）。因此，当你往 ArrayList<integer></integer> 中添加 int 值时，编译器会自动插入装箱操作（Integer.valueOf(x)），取出时又自动拆箱（intValue()）。这个过程看似透明，实则带来可观的运行时开销——尤其在高频、大数据量场景下。
装箱开销具体体现在哪几个环节
自动装箱不是零成本操作，它涉及三类开销：
-
对象分配与 GC 压力：每次装箱都新建一个
Integer实例（除非命中缓存），频繁创建会加剧堆内存占用和垃圾回收频率； -
缓存查找与边界判断：
Integer.valueOf(int)内部先检查值是否在 [-128, 127] 缓存范围内，需分支判断和数组索引访问； - 间接访问与 CPU 指令增多：拆箱需解引用对象再取字段值，相比直接操作栈上基本类型，多出内存加载、空指针检查等指令。
哪些集合操作最易暴露装箱问题
以下场景中，装箱/拆箱频次高，性能影响显著：
-
循环中反复 add / get：例如
for (int i = 0; i 触发 10 万次装箱； -
数值计算密集型遍历：如
list.stream().mapToInt(Integer::intValue).sum()，虽最终转为原始流，但中间仍经历一次装箱（构造列表时）+ 拆箱（映射时）； -
用作 Map 的 key 或 value（尤其是 int → Integer）：
Map<integer string></integer>插入键值对时，key 装箱不可避免；若 key 是高频变化的计数器，开销累积明显。
如何规避或缓解这类开销
不依赖自动装箱，从数据结构和编码习惯入手优化：
-
优先选用原始类型专用集合库：如 Agrona、JDK Collections Extensions（JDK 21+ preview）或成熟第三方库 fastutil、HPPC，它们提供
IntArrayList、Int2ObjectMap等零装箱容器； -
批量处理时预分配 + 原始数组过渡：若必须用标准集合，可先用
int[]累积数据，最后一次性转换（如Arrays.stream(arr).boxed().collect(Collectors.toList())），减少单次装箱次数； -
避免在热点路径中混用包装类型与基本类型：例如不要写
int x = list.get(i) + 1;（触发拆箱）后又立即list.set(i, x);（再次装箱），改用局部变量暂存原始值，减少来回转换。
简单对比：装箱 vs 原始集合的实际差异
以插入 100 万个 int 到列表为例（JDK 17，HotSpot，禁用逃逸分析干扰）：
-
ArrayList<integer></integer>：约 120–180ms，GC 暂停明显，堆内存峰值增加 ~24MB（每个Integer对象约 24 字节）； -
IntArrayList（fastutil）：约 8–12ms，无对象分配，GC 静默；
差距超 10 倍，且随数据规模扩大呈线性放大趋势。这不是微优化，而是数据密集型应用的关键取舍。
