避免大型数组内存溢出的关键在于分段处理、禁用高开销包装、严控生命周期及必要时使用堆外内存，而非单纯扩容堆空间。
处理大型数组时，内存溢出（OutOfMemoryError: Java heap space）往往不是因为“数据太大”，而是因为一次性加载、未分块、未释放、未规避对象开销等设计细节被忽略。关键不在于“能不能装下”，而在于“怎么装、装多少、装完怎么卸”。
避免一次性全量加载到堆内
直接 new double[1_000_000_000] 会立即申请约 8GB 连续堆内存（不含对象头和对齐），极易失败。即使堆总大小够，JVM 也难以找到足够大的连续空间。
- 改用分段处理：将大数组逻辑切分为多个
chunkSize = 100_000的子区间，每次只操作一个 chunk - 避免中间集合缓存：不用
Arrays.asList(bigArray)或Stream.of(bigArray).toList()，它们会复制或包装全部元素 - 若需遍历原始数据，优先用传统 for 循环（索引访问），避免
for-each在Object[]上触发隐式装箱/引用膨胀
慎用高开销的数据结构替代原生数组
原生数组（int[]、double[]）是内存最紧凑的存储形式；换成 List<Integer> 或 ArrayList<Double>，内存占用可飙升 3–5 倍。
-
Integer对象本身约 16 字节 + 引用 4 字节（压缩指针），比int（4 字节）大 4 倍以上 - 不要为遍历而把
int[]转成Stream<Integer>——改用IntStream.range(0, arr.length).mapToObj(i -> arr[i])也不推荐，应直接用IntStream.of(arr)（底层仍复用原数组） - 如需动态扩容或复杂操作，再考虑
TrojanList（Apache Commons Primitives）或MutableIntList（Eclipse Collections）等原生类型集合
主动控制生命周期与内存可见性
大型数组一旦创建，若被长生命周期对象（如 static 字段、缓存 Map、未关闭的流处理器）意外持有，GC 就无法回收，形成事实上的内存泄漏。
立即学习“Java免费学习笔记（深入）”；
- 局部作用域内创建的大数组，确保方法退出前显式置为
null（尤其在 long-running 线程中） - 避免在 lambda 或匿名内部类中捕获大数组引用；若必须，改用局部副本或索引范围参数传递
- 使用
try-with-resources包裹基于数组的缓冲区（如ByteBuffer.wrap(byteArr)），并在 finally 中清零敏感数据（如密码、密钥）
必要时绕过堆内存：堆外数组与内存映射
当数组规模持续超 1GB 且需随机访问，可考虑脱离 JVM 堆管理：
- 用
ByteBuffer.allocateDirect()分配堆外内存，配合asDoubleBuffer()等视图操作，避免堆内拷贝 - 对超大只读文件（如科学计算二进制网格），用
FileChannel.map()映射为MappedByteBuffer，由操作系统按需分页加载 - 注意：堆外内存不受 GC 自动管理，需手动调用
Cleaner或Unsafe.freeMemory()（JDK 14+ 推荐 Cleaner）
