outofmemory 也就是内存溢出报错，核心含义是程序申请的内存已经超过系统或者虚拟机允许的最大内存上限，程序没办法继续分配新内存，就直接抛出 outofmemory 错误，这个报错在 Java 项目最常见，也会出现在 Python C 加加数据库大数据软件里面，很多人看到报错第一反应是直接加内存，但是这只是临时手段，如果代码本身存在内存泄漏，就算加大内存，运行一段时间依旧会再次触发 outofmemory，完整处理思路是先临时恢复业务，再定位根本原因，区分是一次性数据量太大，还是程序持续占用内存不释放，两种情况解决方式完全不一样，日常开发运维里面，这个报错属于高频故障，掌握排查步骤可以快速解决 outofmemory 问题。

报错核心成因原理

outofmemory 本质就是可用内存耗尽，主要分成四大类原因

第一类 堆内存不足，一次性加载超大文件 超大集合 全表查询，短时间占用巨量堆内存

第二类 内存泄漏，对象创建之后一直被引用，垃圾回收器无法回收，内存随运行时间持续上涨，最后触发 outofmemory

第三类 元空间或者栈内存超限，Java 里面类加载太多元空间爆满，递归无限调用造成栈溢出

第四类 系统物理内存本身不够，服务器总内存很小，多个进程同时争抢内存，系统整体资源不足

分级处理步骤

第一步 紧急临时处理

重启报错程序，释放已经占用的内存，让业务先恢复运行，同时立刻保留现场日志，不要直接清空日志，方便后续排查 outofmemory

第二步 确认报错类型

查看完整异常堆栈，判断是 Java heap space 也就是堆溢出，还是 Metaspace 元空间溢出，或者是 unable to create new native thread 线程过多报错

第三步 临时调大内存参数

Java 项目修改启动参数，调整 Xmx 最大堆内存，Xms 初始堆内存，元空间 MaxMetaspaceSize 同步调大，注意不能超过服务器物理内存，还要预留系统本身需要的内存，不能把全部物理内存都分配给程序

第四步 深度定位根因

开启堆转储 dump，程序触发 outofmemory 的时候自动生成 dump 文件，使用 MAT JProfiler 这类分析工具，打开 dump 文件，查看占用内存最高的对象，找到泄漏代码或者超大集合

第五步 代码修复

优化全量查询改成分页查询，大文件改成流式读取，关闭不再使用的连接缓存，移除无效静态引用，修复内存泄漏代码

第六步 长期监控

增加内存监控，采集堆内存使用率，GC 日志，设置告警，在内存快要满的时候提前预警，避免突发 outofmemory

常见场景对比表格

关键注意事项

调大内存只是缓解方案，如果是内存泄漏，盲目加大 Xmx 会让 GC 停顿时间变长，服务器响应变慢，甚至触发系统 OOM killer 直接杀掉进程。

Windows 程序出现 outofmemory，除了程序本身，还要考虑 32 位程序限制，32 位进程最大可用内存只有大约 2GB，就算服务器内存很大，32 位程序也会很早触发 outofmemory，这种情况需要换成 64 位版本程序。

【常见问题】

问题 1 outofmemory 报错是不是只要加大内存就可以彻底解决

回答 1 outofmemory 报错不能只靠加大内存彻底解决，如果是内存泄漏导致的 outofmemory，加大内存只是延后报错时间，必须修复代码里不释放内存的问题，才能根治 outofmemory。

问题 2 Java 项目 outofmemory 怎么生成 dump 文件

回答 2 Java 项目解决 outofmemory 的时候，可以在启动参数添加 HeapDumpOnOutOfMemoryError，程序触发 outofmemory 的时候自动生成堆 dump 文件，再使用 MAT 工具分析 outofmemory 对应的内存占用对象。

问题 3 32 位程序为什么很容易出现 outofmemory

回答 3 32 位程序存在地址空间上限，就算服务器物理内存充足，进程可分配内存也受限，所以 32 位程序更容易触发 outofmemory，升级为 64 位程序可以解除这个限制，减少 outofmemory 出现概率。

【免责申明】

本文为技术排查参考内容，不同编程语言不同软件的 outofmemory 机制存在差异，生产环境修改内存参数和 dump 分析请做好业务备份，重大故障请结合官方文档和专业运维人员评估。