场景项目中有一个接口会进行全表查询查出来3万条查一次不会导致oom但是频繁调用这个接口上一次调用还没有来得及进行垃圾回收下一次接口调用又来了又有3万条数据调用次数多了jvm内存里面的数据就多了而且垃圾回收并不是立马就回收的jvm堆内存空间还没有来得急腾出来所以导致jvm内存溢出。一、你的逻辑完全正确单次查询 3 万条 → 对象虽多但不至于直接 OOM接口频繁被调用上一批对象还在使用 / 还没进入 GC 回收阶段新一批 3 万对象又进来了对象越堆越多进入老年代最终堆内存不足 → FullGC 频繁 → OOM这个逻辑非常真实属于典型的高频大对象压力导致的 OOM不是代码 Bug 级内存泄漏是流量 大对象 GC 不及时共同导致的溢出。二、面试最稳口述版直接照着说之前项目里有个接口逻辑是全表查询一次大概查询 3 万条数据。单次调用其实不会 OOM但是接口被频繁调用并发量上来之后问题就出现了。上一次查询加载到 JVM 里的这批对象还没来得及被 GC 回收下一次请求又进来了又加载 3 万条新对象。多次调用叠加之后堆里的对象越来越多直接进入老年代老年代很快被占满触发频繁 FullGC最终堆内存不够导致了 OOM。然后补一句解决方案加分后来优化方案就是把查询改成分页批量处理并且控制接口并发同时适当调整了新生代空间让短生命周期对象能在 YoungGC 及时回收问题就解决了。三、面试官绝对不会再怼你因为你这次清晰表达了OOM 出在JVM 堆原因是频繁调用 对象堆积 GC 不及时和 Redis 一毛钱关系都没有场景真实、合理、符合生产环境完整版面试口述OOM 场景之前线上遇到过一次JVM 堆内存溢出 OOM。刚开始发现接口偶尔超时服务偶尔卡顿后来直接抛出java.lang.OutOfMemoryError: Java heap space。排查过程我先是通过监控平台看了 GC 情况发现YGC 很频繁FullGC 也在不断增多而且老年代内存回收不下去。然后用jstat -gc观察了一段时间确认是堆内存持续上涨。接着使用jmap导出了堆 dump 文件用MAT工具分析发现堆里大量存在某张表的实体类对象数量非常多。同时我也用Arthas在线上跟踪接口调用定位到是一个全表查询接口一次会查询大约3 万条数据。原因分析这个接口单次调用不会 OOM但是被频繁调用。上一次查询加载到 JVM 里的 3 万条对象还没来得及被 GC 回收下一次请求又来了又新产生一批对象。多次调用叠加之后短生命周期对象大量堆积直接进入老年代老年代很快被占满触发频繁 FullGC最终内存不够用导致 OOM。解决方案把原来的全表查询改成分页批量查询每次只查 1000 条处理一批释放一批避免一次性加载大量数据到内存调整 JVM 参数适当加大新生代空间让这类短生命周期对象在 YoungGC 就能被回收对接口做限流防止瞬间压力过大。优化结果优化之后堆内存明显平稳FullGC 基本消失服务不再 OOM接口响应也稳定了。重点亮点面试官会觉得你很专业用到工具jstat看 GCjmap导出堆MAT分析内存Arthas线上定位接口逻辑清晰频繁调用 → 对象堆积 → 进入老年代 → FullGC 频繁 → OOM不说错概念不提 Redis不说内存泄漏分清 JVM 内存和其他无关组件