大对象（如超大数组）在JVM中需连续堆内存，即使总空间充足，碎片化导致无法分配连续块时会抛出OutOfMemoryError: Java heap space；排查需结合日志中的大数组创建上下文、堆转储中最大数组实例及GC日志中的连续空间告警信号，并通过流式处理、buffer复用或切换G1/ZGC等优化。
基本类型数组（如 byte[]、int[]、double[]）在 JVM 中属于对象，分配在堆上。当请求一个超大数组（例如 new byte[2GB]），JVM 需要一块连续的空闲堆内存空间。即使总剩余堆内存足够，若碎片化严重、无法凑出连续区域，就会直接抛出 java.lang.OutOfMemoryError: Java heap space——这不是“总量不够”，而是“块不够大”。排查这类 OOM，关键在于识别“大数组申请”和“堆碎片”两个核心特征。
确认是否为大数组触发的 OOM
查看错误日志中的堆栈和上下文：
- 检查 OOM 日志是否紧随明显的大数组创建操作，例如
new byte[size]、new int[n]，尤其注意size是否接近或超过几百 MB； - 留意业务场景：文件全量读取（
Files.readAllBytes()）、图片/音视频缓冲区、批量导出生成大字节数组、缓存预分配等； - 对比 GC 日志：若 OOM 前老年代已满但年轻代尚有空间，或 GC 后堆使用率未显著下降，说明不是常规对象堆积，更可能是单次大块分配失败。
用堆转储定位最大数组实例
启用 -XX:+HeapDumpOnOutOfMemoryError 后，用 MAT 或 JProfiler 分析 dump 文件：
- 打开 “Histogram” 视图，按 Shallow Heap 降序排列，重点关注
[B（byte 数组）、[I（int 数组）、[C（char 数组）等原生数组类； - 找到占用最大的几个数组实例，右键 → “List objects” → “with incoming references”，看谁在持有它（例如某个 Service 方法的局部变量、静态缓存 Map 的 value）；
- 若发现多个超大数组（如多个 500MB+ 的
byte[]），且它们生命周期重叠、未及时释放，基本可锁定为问题源头。
检查堆碎片与 GC 行为
连续空间不足往往伴随 GC 效率恶化：
- 开启详细 GC 日志（
-Xlog:gc*:file=gc.log:time,uptime），关注是否频繁出现 “Full GC” 或 “Concurrent Mode Failure”； - 观察 GC 日志中每次回收后 “heap” 区域的 “used” 和 “capacity” 差值是否稳定，但最大可用连续块（可通过
jstat -gc <pid>中的CCSU/CCU辅助判断，或用 G1 的Region Usage分析）持续偏小； - 若使用 CMS，注意 “Promotion Failed”；若使用 G1，关注 “to-space exhausted” 或 “evacuation failure” —— 这些都是连续空间告急的信号。
针对性解决与规避
不能只靠调大 -Xmx，必须从分配方式入手：
- 禁止一次性加载整个大文件：改用流式处理（
InputStream+ 小 buffer）、分片读取、内存映射（MappedByteBuffer）； - 避免手动预分配巨型数组：用动态扩容的集合（如
ByteArrayOutputStream）替代new byte[1024*1024*1024]； - 对已知需大缓冲的场景（如解压缩、加解密），显式控制 buffer 大小上限，并复用
ThreadLocal<byte[]>减少重复分配； - 考虑切换垃圾收集器：G1 或 ZGC 对大对象和碎片管理更友好，G1 中大于 50% region size 的对象会直接进入老年代（避免年轻代复制失败），ZGC 几乎无停顿且不惧碎片。
