您是否处理内存不足的情况？

malloc返回0或新引发异常时该怎么办？只是停止还是尝试在OOM条件下生存/保存用户的工作？

我会像避免崩溃一样避免OOM。

避免一次执行大量工作（并分配大量内存）。将数据保留在磁盘上，信任OS磁盘缓存，并尽可能多地使用内存映射的IO，并且一次只能处理一小部分数据。如果需要在线存储大量数据（以低延迟提供），则像所有大型搜索引擎公司一样，将它们保存在多台计算机的内存中。或购买SSD。

回答这个问题的大多数人可能从未在嵌入式系统上工作过，因为malloc返回0的可能性非常大。在我当前正在使用的系统上，总共有4.25K字节的RAM（即4352字节）。我为堆栈分配了64个字节，当前有1600个字节的堆。就在昨天，我正在调试堆遍历例程，以便可以跟踪内存的分配和释放。堆遍历使用一个小的（30字节）静态分配的缓冲区输出到串行端口。对于发行版本，它将关闭。

由于这是消费类产品，因此最好不要在产品发布后耗尽内存。我相信它将在开发过程中。无论如何，我所能做的就是让扬声器发出几次哔声，然后重新启动。

老实说，在我完成的所有项目中（请记住，我还没有在任何地方工作），我从来没有考虑过可能发生这种情况，因此我想我的程序会很快死掉。

此外，处理OOM要求您预先分配资源以显示错误消息或保存所有内容，这可能会带来不便。

我觉得这些天，内存的花费要比花生便宜，这不是应该经常发生的事情。在受保护的记忆之初以及之前，也许这是个问题，但是现在呢？我见过的唯一的OOM错误是来自错误代码。

无论如何，检查malloc返回代码通常是毫无意义的。

现代操作系统过量使用内存：它们为进程提供的内存超过了实际可用的内存。授予您的进程的内存是虚拟的，所有内存都映射到单个清零页面。

直到您写入内存后，才会为进程分配一个物理的唯一页面。如果此分配失败，内核将终止进程（也许是您的进程！）以尝试查找内存。到那时，您无能为力了。

除非您是为嵌入式系统，实时系统或如此关键的系统而开发，否则故障可能会导致生命或数十亿美元的损失。

在大多数情况下，无论如何，当您的内存不足时，几乎无能为力，因为没有内存可以创建任何新对象或执行任何可能做某事的任务。您必须权衡处理OOM的应用程序成本与从中获得的收益。

我将始终检查错误。如果某些内容返回错误情况，则必须由程序处理。即使该消息说“内存不足，该走了！”，它也比“访问冲突”，“核心已转储”或其他任何方法要好。一个是您处理的错误条件，另一个是错误。并且用户也将同样如此。

对于您的特定情况，您可以尝试回滚操作，释放分配的资源，直到达到故障点为止，报告错误，然后继续执行（也许在尝试退出应用程序时，您可以选择立即退出）。这样，用户可以决定该怎么做，或尝试通过摆弄，关闭文件等来释放一些内存。当然，如何处理这种情况在很大程度上取决于您的程序-该程序不应进行交互可能只需要记录错误并退出或继续即可。