基本类型数组不产生内存碎片，包装类数组因每个元素独立分配对象而显著加剧堆内存碎片化；前者连续紧凑，后者引发频繁小块分配释放、gc压力增大及full gc风险。
基本类型数组本身不产生内存碎片，包装类数组则显著加剧堆内存碎片化——关键不在“数组”本身，而在每个元素是否独立分配对象。
基本类型数组：连续、紧凑、无碎片
int[] arr = new int[10000]; 这样的数组在堆中分配一块连续内存：对象头（16字节）+ 40,000 字节数据（10000×4），总大小 40,016 字节。JVM 一次性申请固定长度的连续空间，后续访问局部性好，GC 压力小，不引入碎片。
包装类数组：双重碎片源
Integer[] arr = new Integer[10000]; 这行代码只创建一个数组对象（16字节头 + 10000×8字节引用 = 约 80,016 字节），但真正的问题在初始化后：
- 每个 Integer 对象单独分配：如用 new Integer(1) 或未命中缓存的 Integer.valueOf(200)，会在堆中各自申请约 24 字节（对象头16 + 值4 + 填充4），且这些分配彼此不连续；
- 频繁创建/销毁时，小块内存被反复分配释放，易留下无法利用的间隙；
- 即使使用缓存（-128~127），也只缓解部分场景；超出范围仍触发大量独立堆分配。
实际影响不止于“占用多少”
碎片化会拖慢后续内存分配速度，增加 GC 频率（尤其 CMS 或 G1 中的 Mixed GC 阶段），还可能引发 Full GC。比如 10 万个 Integer 对象若分散在不同内存页，Minor GC 后存活对象复制成本高，老年代晋升也更早。
规避建议
- 优先用基本类型数组（int[]、long[] 等），配合 FastUtil、Trove 或 Eclipse Collections 等原生支持基本类型的集合库；
- 必须用包装类数组时，尽量复用已缓存实例（如只用 -128~127 范围的 Integer）；
- 避免在循环内反复 new 包装类对象，改用 valueOf 或提前构建池化对象；
- 对超大数组场景，考虑分块处理或内存映射（MappedByteBuffer）替代堆内对象阵列。
