int[]比ArrayList节省内存的核心在于消除对象头、引用指针和Integer包装实例的冗余开销，而非内存对齐；以百万整数为例，int[]约4MB，ArrayList达20–24MB，差距4–6倍，且int[]连续布局更缓存友好。
![java 中性能优化 怎么利用基本数据类型数组（如 int[]）替换包装类集合以大幅消灭对象的内存对齐开销](https://img.php.cn/upload/article/001/242/473/178504179832641.jpeg)
Java 中用 int[] 替代 ArrayList<integer></integer> 确实能显著降低内存占用和 GC 压力，但核心收益不在于“内存对齐开销”，而在于消除对象头、引用指针、包装类实例本身带来的冗余内存和间接访问成本。所谓“内存对齐”是底层硬件或 JVM 内存分配策略的副产物，并非主要瓶颈；真正关键的是减少堆上对象数量和提升数据局部性。
为什么 int[] 比 ArrayList 节省内存？
以存储 100 万个整数为例：
-
int[1_000_000]：约 4MB（每个 int 占 4 字节，连续紧凑存储） -
ArrayList<integer></integer>：至少 20–24MB 以上 —— 包含：- 100 万个
Integer对象，每个对象有 12 字节对象头 + 4 字节 value（在压缩普通对象指针下），共约 16 字节/个 → ~16MB - 内部
Object[]数组（存的是引用），每个引用占 4 或 8 字节（取决于是否开启 CompressedOops），加上数组对象头 → ~4–8MB - ArrayList 实例自身开销（size、modCount 等）可忽略，但间接引用导致 CPU 缓存行利用率下降
- 100 万个
实际差距常达 4–6 倍，且 int[] 全部连续布局，CPU 缓存友好；而 Integer 分散堆中，随机访问易引发 cache miss。
如何安全、高效地替换？
不是简单把 ArrayList 改成 int[] 就完事——需兼顾可变性、空值语义、API 兼容性：
立即学习“Java免费学习笔记（深入）”；
-
明确容量是否固定：若长度确定（如解析固定格式日志、图像像素、数学向量），直接用
int[]最优；若需频繁增删，优先考虑TIntArrayList（Trove）或IntArrayList（Eclipse Collections），它们内部用原生数组 + 动态扩容，避免装箱 -
处理“空值”需求：
int[]无法表示 null。若业务逻辑需要缺失值标记，约定一个哨兵值（如-1、Integer.MIN_VALUE），并配合布尔数组或位图记录有效性；或改用OptionalInt[]（不推荐，又引入对象） -
避免隐式装箱场景：传参时别写
Arrays.asList(new int[]{1,2,3})—— 这会生成List<int></int>，而非List<integer></integer>；要用就用IntStream.of(1,2,3).boxed().collect(...)，但这就又回到包装类了
哪些场景特别适合原生数组？
以下情况几乎总是优先选 int[]（或 long[]、double[] 等）：
- 数值计算密集型：矩阵运算、FFT、统计聚合（sum/max/min/count）、滑动窗口等 —— JIT 更容易向量化（如使用 AVX 指令）
- 序列化/IO 缓冲：网络协议解析（如 protobuf repeated int32）、文件读写（二进制格式）、GPU 数据传输 —— 避免序列化包装类的额外字段和嵌套结构
-
高频缓存数据：比如 LRU 缓存的 key 哈希码数组、布隆过滤器的 bit array（用
long[]实现）、时间序列时间戳/值双数组
注意边界与权衡
原生数组不是银弹：
-
不可变长度：扩容需手动
Arrays.copyOf()，比ArrayList的自动扩容更易出错 -
缺乏内置算法支持：排序、查找、流式操作需调用
Arrays.sort()、Arrays.binarySearch()或IntStream，语法略冗长 -
线程安全需自行保障：
int[]本身无同步机制，多线程写入需加锁或用AtomicIntegerArray -
泛型不兼容：无法直接用于依赖
List<? extends Number>的通用工具方法，需封装适配器或改用第三方原生集合库
