兼职铲屎官你正在电脑前写一份重要文档，突然风扇狂转，鼠标开始飘，接着屏幕上弹出一行字："内存不足，请关闭一些程序后重试"——如果发生在服务器上，更狠，系统直接挑一个进程杀掉，只留下一行 Killed process 日志就没了下文。OOM（Out Of Memory，内存不足）和高内存消耗，大概是IT领域最普遍、也最容易被误判的问题。我见过太多人一看到内存飙升就重启大法，结果第二天原样再炸一次。这篇文章把OOM的故障排除步骤完整梳理一遍：从区分系统级和应用级，到定位高内存消耗的现场手段，再到线上快速定位链路，以及几个热搜里高频出现的真实场景。不管你是运维、后端开发，还是SolidWorks、浏览器、Zotero这类软件的普通用户，都能找到对应自己能用的那一节。
1. "内存不足"不等于"物理内存不够"：先分清系统级与应用级
遇到OOM，第一件事不是查代码，而是先确认这个"内存不足"到底是谁报出来的。系统报的，还是程序报的，处理方向完全不同。
1.1 系统级OOM：整个机器都到极限了
Linux上最常见。当物理内存和swap（交换分区）全部耗尽时，内核的OOM Killer会被触发，它根据每个进程的 oom_score 挑一个"最该杀"的进程，直接kill掉。所以Linux上经常会发生"某个不起眼的进程突然消失"的情况，你翻 /var/log/messages 或 dmesg，里面有一行 Out of memory: Killed process 12345 (java)。这就是系统级OOM：不是某个程序想不开，而是整台机器的内存预算烧完了，内核强制清场。
Windows也有类似机制，但表现更隐蔽。Windows有一个"提交限制"（Commit Limit），数值等于物理内存加页面文件（pagefile）的总量。当所有进程提交的内存总和逼近上限，新的大块内存分配请求就会失败，程序收到"内存不足"提示或者直接崩溃。早年32位Windows进程默认只有2GB用户态地址空间，所以"内存不足"特别频繁。现在64位普及了，但很多老软件、老插件仍是32位，这个坑依然存在。macOS这边则体现为"内存压力"变红、swap使用率飙升、整机响应变慢，个别进程被系统强制退出。
判断系统级OOM的标准很直接：看整机物理内存和swap是否被吃满。吃满了，就是系统级问题，你要处理的是"为什么这台机器内存用了这么多"，而不是只盯着某一个程序。
1.2 应用级OOM：程序自己把自己撑爆
另一种情况是系统内存还挺宽裕，但某个进程内部的内存区域爆了。最典型的是Java进程报 java.lang.OutOfMemoryError: Java heap space，Node.js进程报 JavaScript heap out of memory。这种情况下操作系统活得好好的，但程序内部用来存放对象和变量的"堆内存"到了上限，后续再新建对象分配不到空间，只能抛异常。
应用级OOM还有一种隐蔽变体，叫 GC overhead limit exceeded。它指的是JVM的垃圾回收器几乎把所有CPU时间都花在了回收上，但每次回收掉的内存又极其有限，JVM觉得继续跑下去没有意义，主动宣布"我不行了"。可以理解成一个仓库管理员把所有时间都用来倒腾货物，结果仓库里的垃圾还是越堆越多，人先崩溃了。
桌面软件也一样。SolidWorks打开超大STEP文件时提示内存不足，很多时候就是应用级问题：软件内部要加载几何数据、构建特征树、生成预览渲染，每一步都会产生数倍于文件体积的内存占用。文件500MB，内存里膨胀到5GB甚至更多，非常正常。
1.3 五花八门的提示语背后是同一类病因
我把常见提示语和它们对应的场景整理成一张表，方便你看到报错时快速判断方向：
| 提示语示例 | 常见场景 | 大概率病因 |
|---|---|---|
Out of memory: Killed process |
Linux服务器进程消失 | 系统级，物理内存+swap耗尽 |
内存不足，无法完成操作 |
Windows桌面应用、大文件操作 |