《技术底稿 40》别只看文件大小：一次 “反常 OOM” 背后的内存缓存重构
一、反常现象：小文件报错，大文件反倒正常
业务场景需批量导入文献类 ZIP 压缩包。
本次测试出现诡异问题：一个282MB 的 ZIP 包导入时，直接抛出java.lang.OutOfMemoryError: Java heap space堆内存溢出。
当前服务 JVM 堆内存固定配置：-Xmx512m。
更反常的是：历史导入近 500MB 同款压缩包完全正常。更小的文件崩、更大的文件能跑，明显不符合直觉，必须深挖底层原因。
二、对比：不同导入策略的内存表现
项目中存在两套文件导入逻辑，差距极大：
| 导入策略 | 文件类型 | 处理逻辑 | 内存风险 |
|---|---|---|---|
| 常规导入 | 纯 PDF 附件 | 边读边处理，不缓存 | ✅ 安全 |
| 文献混合导入 | Excel 台账 + PDF 附件 | 全部读完统一缓存再处理 | ❌ 极易 OOM |
根因非常明确：
文献导入旧逻辑采用全量缓存写法。
遍历 ZIP 过程中，把所有 PDF 的 byte [] 全部存入 Map常驻内存，Excel 也一次性读取加载。
必须等整包遍历结束、Excel 解析完成，才开始匹配附件、执行业务处理。
导致：内存峰值 = 压缩包内所有 PDF 体积总和，极易打满堆内存。
三、反常现象的真正原因
核心认知：磁盘文件大小 ≠ JVM 内存占用
真正决定崩不崩的，是包内文件结构：
- 500MB 成功包：文件细碎、单体小 → 内存峰值平缓，扛得住 512M
- 282MB 失败包：少量超大 PDF 文件 → 瞬时内存暴涨，直接溢出
看似矛盾的现象，本质是代码缓存机制带来的内存峰值差异。
四、改造方案：二次遍历 + 只存索引、不存内容
不改业务逻辑，只优化读取流程，彻底根治 OOM。
核心思路
第一轮遍历：只读台账只解析 Excel，生成文献业务列表，建立「文件名→业务 DTO」索引映射，不缓存任何文件字节。
第二轮遍历：边读边处理重新遍历 ZIP，读到 PDF 立即匹配索引、立即处理，用完即刻释放内存，支持 GC 回收。
关键改动
- 删除全量缓存 PDF 的 Map 存储逻辑
- 拆分「读取文件」和「业务处理」流程
- 从一次性加载全部改为单文件流式处理
五、改造前后对比
表格
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 内存峰值 | 所有 PDF 体积总和 | 单文件最大体积 |
| 512M 堆运行 | OOM 崩溃 | 稳定运行 |
| 读取模式 | 全量缓存加载 | 流式分次读取 |
六、验证结果
优化后重新完整实测：
- 批量关联有效文献：116 条
- 导入成功：116 条，失败：0 条
- 无 OOM、无报错、无数据错乱
- 整体执行耗时：约 2 秒
数据完整入库，业务运行稳定。
七、复盘经验
- 不要以磁盘大小判断内存压力，代码缓存逻辑才是内存瓶颈的核心。
- 批量压缩包解析，优先流式处理，坚决避免全量驻留内存。
- 「Excel 台账 + 附件匹配」场景是高频坑点，必须采用两次遍历、索引解耦的方式优化。
- 反常 BUG 最有价值，通过正反场景对比，能快速挖出隐蔽架构缺陷。
八、文末总结
本篇为线上文件导入内存溢出真实排查复盘，针对小文件反常 OOM 问题，对比多套业务处理逻辑，定位全量缓存设计缺陷。
通过二次遍历重构读取流程，砍掉无效内存占用，在不改动核心业务的前提下，彻底解决堆溢出故障。
文章涵盖文件压缩包处理、JVM 内存优化、业务逻辑避坑等实战内容，总结批量附件导入通用设计思路，同类文件上传、批量解析场景均可参考复用。
《技术底稿》系列第 40 篇，记录线上隐蔽内存问题排查全过程，留存问题定位、代码改造、效果验证完整流程，助力后端开发规避同类内存隐患。