JVM堆内存耗尽导致OOM，主因包括堆配置过小、突发流量、内存泄漏、超大对象分配及过度缓存；后果含进程崩溃、GC频繁、CPU飙升；需通过GC日志、堆转储分析定位，再调参或修代码解决。
这个错误本质是 JVM 堆内存被彻底用尽，无法再为新对象分配空间——哪怕物理内存还很充裕，只要堆上限（-Xmx）到了，就会立刻报错。
典型前因：什么情况会把堆撑爆
不是所有“内存不够”都一样，得看堆是怎么被占满的：
-
堆配置过小：比如一个要处理百万级订单的服务，只配了
-Xmx512m，启动就埋下隐患； - 突发流量或数据量飙升：秒杀活动时并发请求激增，每个请求缓存一份商品快照，瞬间生成数万临时对象；
- 内存泄漏：静态集合持续 add、线程局部变量未清理、监听器注册后没反注册、数据库连接/流未 close，对象长期驻留堆中无法回收；
-
单次申请超大对象：如
new byte[200 * 1024 * 1024]（200MB 字节数组），直接超过剩余堆空间； -
过度缓存：把整张用户表查出来塞进
static Map<long user></long>，且永不淘汰。
关键后果：不只是程序崩溃
它往往不是孤立事件，会连锁引发其他问题：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 应用进程直接 OOM Crash，服务不可用；
- GC 频繁触发，CPU 持续飙高，响应延迟急剧上升（即使还没 crash）；
- 可能伴随 GC overhead limit exceeded 错误，说明 GC 已经“徒劳挣扎”；
- 日志中反复出现 Full GC 记录，但老年代占用率持续 95%+，这是泄漏的强信号。
实用应对套路：三步定位 + 两路解决
别一上来就加内存，先分清是“真不够”还是“被堵死”：
立即学习“Java免费学习笔记（深入）”；
-
第一步：确认是不是真缺内存 —— 加 JVM 参数
-XX:+PrintGCDetails -Xloggc:gc.log，观察 GC 日志。如果每次 Full GC 后老年代回收极少（比如只降 1%），基本可断定是泄漏； -
第二步：抓堆快照分析根因 —— 出现 OOM 时自动导出堆转储：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/，再用 Eclipse MAT 或 VisualVM 查看“支配树（Dominator Tree）”，找占用最大的类和引用链； - 第三步：复现+验证 —— 在测试环境模拟相同负载，用 JProfiler 或 Arthas 实时监控对象创建速率与堆使用趋势；
-
短期解法：调堆 —— 确认是真实容量不足（如处理大数据报表），合理上调
-Xms和-Xmx，建议设为相等避免动态扩容开销，例如-Xms2g -Xmx2g； - 长期解法：修代码 —— 清理静态集合、用 WeakReference/SoftReference 管理缓存、流/连接必须 try-with-resources、分页查库不查全表、引入本地缓存淘汰策略（如 Caffeine 的 maximumSize）。
预防性习惯：让 OOM 少敲门
上线前和迭代中主动卡住风险点：
- 所有新功能上线前做内存压测，监控堆增长曲线；
- 核心服务 JVM 启动必加
-XX:+HeapDumpOnOutOfMemoryError； - 静态集合类必须配注释说明生命周期，定期 Code Review；
- 用
java -XX:+PrintFlagsFinal | grep MaxHeapSize核对实际生效的堆上限，防止参数传错或被覆盖。
