“内存不足” 可恢复的错误？

Question

我已经编程很长时间了，我看到的程序，当内存不足时，会尝试清理并退出，即优雅地失败。 我不记得上次看到有人真正尝试恢复并继续正常运行是什么时候。

如此多的处理依赖于能够成功分配内存，尤其是在垃圾收集语言中，似乎内存不足错误应该被归类为不可恢复的错误。 （不可恢复的错误包括堆栈溢出之类的情况。）

使其成为可恢复错误的令人信服的论据是什么？

Answer 1

我知道你要求论证，但我只能看到反对的论证。

无论如何，我看不到在多线程应用程序中实现这一点。 您如何知道哪个线程实际上对内存不足错误负责？ 一个线程可以不断分配新内存，并且具有 99% 的堆的 gc-roots，但第一次分配失败发生在另一个线程中。

一个实际的例子：每当我的 Java 应用程序（在 JBoss 服务器上运行）中发生 OutOfMemoryError 时，它并不像一个线程死亡而服务器的其余部分继续运行：不，有几个 OOME，杀死了几个线程（一些其中是JBoss的内部线程）。 我不知道作为一名程序员我可以做些什么来从中恢复，甚至不知道 JBoss 可以做些什么来从中恢复。 事实上，我什至不确定你可以： javadoc for VirtualMachineError 表明，抛出此类错误后，JVM 可能会“损坏”。 但也许这个问题更针对语言设计。

Answer 2

uClibc 有一个 8 字节左右的内部静态缓冲区，用于在没有更多内存可动态分配时用于文件 I/O。

Answer 3

使其成为可恢复错误的令人信服的论据是什么？

在 Java 中，不使其成为可恢复错误的一个令人信服的论据是，Java 允许在任何时间发出 OOM 信号，包括结果可能是您的程序进入的时间不一致的状态。 因此，从 OOM 中可靠地恢复是不可能的； 如果捕获 OOM 异常，则不能依赖任何程序状态。 看
不抛出 VirtualMachineError 保证

Answer 4

我正在研究 SpiderMonkey，这是 Firefox（以及 gnome 和其他一些）中使用的 JavaScript VM。 当内存不足时，您可能需要执行以下任一操作：

1. 运行垃圾收集器。 我们不会一直运行垃圾收集器，因为它会降低性能和电池电量，因此当您遇到内存不足错误时，可能已经积累了一些垃圾。
2. 释放内存。 例如，删除一些内存缓存。
3. 终止或推迟非必要的任务。 例如，从内存中卸载一些长时间不用的选项卡。
4. 记录日志以帮助开发人员解决内存不足错误。
5. 显示一条半友好的错误消息，让用户知道发生了什么。
6. ...

所以，是的，有很多原因需要手动处理内存不足错误！

Answer 5

我有这个：

void *smalloc(size_t size) {
  void *mem = null; 
  for(;;) {
   mem = malloc(size);
   if(mem == NULL) {
    sleep(1);
   } else 
     break;
  }
  return mem;
}

它已经保存了系统几次。 仅仅因为您现在内存不足，并不意味着系统的其他部分或系统上运行的其他进程有一些内存，它们很快就会归还。 在尝试这些技巧之前，您最好非常小心，并完全控制您在程序中分配的每个内存。

Answer 6

这实际上取决于您正在构建的内容。

对于网络服务器来说，一个请求/响应对失败但随后继续处理进一步的请求并不是完全不合理的。 然而，您必须确保单一故障不会对全局状态产生有害影响 - 这将是棘手的一点。 鉴于故障会在大多数托管环境（例如 .NET 和 Java）中导致异常，我怀疑如果在“用户代码”中处理该异常，则将来的请求可以恢复该异常 - 例如，如果一个请求尝试分配 10GB 内存并且失败了，这不会损害系统的其余部分。 然而，如果系统在尝试将请求交给用户代码时内存不足，那么这种情况可能会更糟糕。

Answer 7

在库中，您希望高效地复制文件。 当您这样做时，您通常会发现使用少量大块进行复制比复制大量较小块更有效（例如，通过复制 15 个 1MB 块来复制 15MB 文件比复制 15,000 个块要快） 1K 块）。

但该代码适用于任何块大小。 因此，虽然使用 1MB 块可能会更快，但如果您为复制大量文件的系统进行设计，那么捕获 OutOfMemoryError 并减小块大小可能是明智之举，直到成功为止。

另一个地方是存储在数据库中的对象的缓存。 您希望在缓存中保留尽可能多的对象，但又不想干扰应用程序的其余部分。 由于可以重新创建这些对象，因此将缓存附加到内存不足处理程序以删除条目，直到应用程序的其余部分再次有足够的空间呼吸，这是节省内存的明智方法。

最后，对于图像处理，您希望将尽可能多的图像加载到内存中。 同样，OOM 处理程序允许您在不事先知道用户或操作系统将授予您的代码多少内存的情况下实现这一点。

[编辑] 请注意，我在这里工作的假设是您已经为应用程序提供了固定数量的内存，并且该数量小于不包括交换空间的总可用内存。 如果您可以分配如此多的内存以至于必须换出一部分内存，那么我的一些评论就不再有意义了。

Answer 8

MATLAB 用户在对大型数组执行算术运算时总是会出现内存不足的情况。 例如，如果变量 x 适合内存并且运行“x+1”，则 MATLAB 会为结果分配空间，然后填充它。 如果分配失败，MATLAB 会出错，用户可以尝试其他方法。 如果每当出现此用例时 MATLAB 就退出，那将是一场灾难。

Answer 9

OOM 应该是可恢复的，因为关闭并不是从 OOM 恢复的唯一策略。

对于应用程序级别的 OOM 问题，实际上有一个相当标准的解决方案。
作为应用程序设计的一部分，确定从内存不足情况中恢复所需的安全最小内存量。 （例如，自动保存文档、弹出警告对话框、记录关机数据所需的内存）。

在应用程序启动时或关键块开始时，预先分配该内存量。 如果您检测到内存不足的情况，请释放您的保护内存并执行恢复。 该策略仍然可能会失败，但总体而言是物有所值的。

请注意，应用程序不需要关闭。 它可以显示模式对话框，直到 OOM 条件得到解决。

我不是 100% 确定，但我很确定“代码完整” （任何受人尊敬的软件工程师必读）涵盖了这一点。

PS您可以扩展您的应用程序框架来帮助实现此策略，但请不要在库中实施此类策略（好的库不会在未经应用程序同意的情况下做出全局决策）

Answer 10

我认为就像许多事情一样，这是成本/收益分析。 您可以通过编程尝试从 malloc() 故障中恢复 - 尽管这可能很困难（您的处理程序最好不要遇到它要处理的内存短缺问题）。

您已经注意到，最常见的情况是清理并优雅地失败。 在这种情况下，我们决定优雅中止的成本低于恢复时开发成本和性能成本的总和。

我相信您可以想到自己的例子，其中终止程序是一个非常昂贵的选择（生命维持机、宇宙飞船控制、长时间运行和时间关键的财务计算等） - 尽管第一道防线是当然要确保程序具有可预测的内存使用情况并且环境可以提供该内存使用情况。

Answer 11

我正在开发一个为 IO 缓存分配内存以提高性能的系统。 然后，在检测到 OOM 时，它会收回其中的一部分，以便业务逻辑可以继续进行，即使这意味着更少的 IO 缓存和稍低的写入性能。

我还使用了一个嵌入式 Java 应用程序，该应用程序尝试通过强制垃圾回收来管理 OOM，并可选择释放一些非关键对象，例如预取或缓存的数据。

OOM处理的主要问题是：

1）能够在发生的地方重试或者能够回滚并从更高的点重试。 大多数当代程序过于依赖语言来抛出，并且没有真正管理它们最终的位置以及如何重试操作。 通常操作的上下文将会丢失，如果它没有被设计为保留

2) 能够实际释放一些内存。 这意味着一种资源管理器知道哪些对象是关键的，哪些不是关键的，并且系统能够在它们以后变得关键时重新请求已释放的对象

另一个重要的问题是能够在不触发的情况下回滚另一种 OOM 情况。 这是在高级语言中很难控制的事情。

此外，底层操作系统对于 OOM 的行为必须是可预测的。 例如，如果启用了内存过量使用，Linux 就不会。 许多支持交换的系统在向有问题的应用程序报告 OOM 之前就会死亡。

而且，在这种情况下，不是您的进程造成了这种情况，因此如果有问题的进程继续泄漏，释放内存也无济于事。

正因为如此，大型嵌入式系统通常会采用这种技术，因为它们可以控制操作系统和内存以实现这些技术，并有实现它们的纪律/动机。

Answer 12

只有抓住并正确处理才能恢复。

例如，在相同的情况下，请求尝试分配大量内存。 这是相当可预测的，你可以很好地处理它。

然而，在很多情况下，在多线程应用程序中，OOE也可能发生在后台线程（包括由系统/第三方库创建的线程）上。
预测几乎是不可能的，并且您可能无法恢复所有线程的状态。

Answer 13

不。
来自 GC 的内存不足错误通常不应在当前线程内恢复。 （不过，应该支持可恢复线程（用户或内核）创建和终止）

关于反例：我目前正在开发一个 D 编程语言项目，该项目使用 NVIDIA 的 CUDA 平台进行 GPU 计算。 我没有手动管理 GPU 内存，而是创建了代理对象来利用 D 的 GC。 因此，当 GPU 返回内存不足错误时，我会运行完整收集，并且仅在第二次失败时引发异常。 但是，这实际上并不是内存不足恢复的示例，它更多的是 GC 集成的示例。 恢复的其他示例（缓存、空闲列表、没有自动收缩的堆栈/哈希等）都是具有自己的收集/压缩内存方法的结构，这些方法与 GC 分离，并且往往不是分配的本地方法。功能。
因此，人们可能会实现如下所示的内容：

T new2(T)( lazy T old_new ) {
    T obj;
    try{
        obj = old_new;
    }catch(OutOfMemoryException oome) {
        foreach(compact; Global_List_Of_Delegates_From_Compatible_Objects)
            compact();
        obj = old_new;
    }
    return obj;
}

一般来说，这是添加对向垃圾收集器注册/取消注册自收集/压缩对象的支持的一个不错的论点。

Answer 14

这个问题被标记为“与语言无关”，但如果不考虑语言和/或底层系统，就很难回答。

如果内存分配是隐式的，没有机制来检测给定的分配是否成功，那么从内存不足的情况中恢复可能会很困难或不可能。

例如，如果您调用一个尝试分配大数组的函数，大多数语言只是不定义无法分配数组时的行为。 （在 Ada 中，这会引发 Storage_Error 异常，至少在原则上是这样，并且应该可以处理该异常。）

另一方面，如果您有一种尝试分配内存并且能够如果报告执行此操作失败（如 C 的 malloc() 或 C++ 的 new），那么是的，当然可以从该失败中恢复。 至少在 malloc() 和 new 的情况下，失败的分配除了报告失败之外不会执行任何操作（它不会损坏任何内部数据结构，例如例子）。

尝试恢复是否有意义取决于应用程序。 如果应用程序在分配失败后无法成功，那么它应该尽其所能进行清理并终止。 但是，如果分配失败仅仅意味着无法执行一项特定任务，或者如果该任务仍然可以使用更少的内存以更慢的速度执行，那么继续操作是有意义的。

一个具体的例子：假设我正在使用文本编辑器。 如果我尝试在编辑器中执行某些需要大量内存的操作，并且该操作无法执行，我希望编辑器告诉我它不能执行我要求的操作并让我继续编辑< /em>. 终止而不保存我的工作将是不可接受的反应。 保存我的工作并终止会更好，但仍然不必要地对用户产生敌意。

Answer 15

一般情况下是无法恢复的。

但是，如果您的系统包含某种形式的动态缓存，则内存不足处理程序通常可以转储缓存（甚至整个缓存）中最旧的元素。

当然，您必须确保“转储”过程不需要新的内存分配:)此外，恢复失败的特定分配可能很棘手，除非您能够将缓存转储代码直接插入分配器级别，以便故障不会传播到调用者。

Answer 16

这取决于您所说的内存不足是什么意思。

当 malloc() 在大多数系统上失败时，这是因为地址空间已用完。

如果大部分内存被缓存或 mmap 区域占用，您可以通过释放缓存或取消映射来回收其中的一些内存。 然而，这确实要求您知道该内存的用途——正如您所注意到的，大多数程序要么不知道，要么它没有什么区别。

如果您对自己使用了 setrlimit() （也许是为了防止不可预见的攻击，或者可能是 root 对您这样做的），您可以放宽错误处理程序中的限制。 我经常这样做——在可能的情况下提示用户并记录事件之后。

另一方面，捕获堆栈溢出有点困难，而且不可移植。 我为 ECL 编写了一个 posixish 解决方案，并描述了 Windows 实现（如果您要走这条路线）。 几个月前它已被检查到 ECL，但如果您有兴趣，我可以挖掘原始补丁。

Answer 17

特别是在垃圾收集环境中，如果您在应用程序的高层捕获 OutOfMemory 错误，则很可能会发现许多内容超出了范围，并且可以回收以恢复内存。

在单个过度分配的情况下，应用程序可能能够继续完美地工作。 当然，如果您有逐渐的内存泄漏，您将再次遇到问题（更可能早晚），但给应用程序一个优雅地停止运行的机会仍然是一个好主意，将未保存的更改保存在GUI应用程序的情况等

Answer 18

是的，OOM是可以恢复的。 作为一个极端的例子，Unix 和 Windows 操作系统在大多数情况下都能很好地从 OOM 条件中恢复。 应用程序失败，但操作系统仍然存在（假设有足够的内存供操作系统正确启动）。

我举这个例子只是为了表明这是可以做到的。

处理 OOM 的问题实际上取决于您的程序和环境。

例如，在许多情况下，最有可能发生 OOM 的位置并不是实际从 OOM 状态恢复的最佳位置。

现在，自定义分配器可以作为代码中处理 OOM 的中心点。 Java 分配器将在实际抛出 OOM 异常之前执行完整的 GC。

您的分配器越具有“应用程序意识”，它就越适合作为 OOM 的中央处理程序和恢复代理。 再次使用 Java，它的分配器并不是特别适合应用程序。

这就是像 Java 这样的东西很容易令人沮丧的地方。 您无法覆盖分配器。 因此，虽然您可以在自己的代码中捕获 OOM 异常，但并不能说明您正在使用的某些库已正确捕获，甚至正确抛出了 OOM 异常。 创建一个永远被 OOM 异常破坏的类是微不足道的，因为某些对象被设置为 null 并且“永远不会发生”，并且它永远无法恢复。

所以，是的，OOM 是可以恢复的，但它可能非常困难，特别是在 Java 等现代环境中，并且有大量不同质量的第三方库。

Answer 19

这是一个很难的问题。 乍一看，失去记忆似乎意味着“运气不好”，但是，您还必须看到，如果一个人真正坚持的话，可以摆脱许多与记忆相关的东西。 让我们以其他方式来看损坏的函数 strtok，一方面它在内存方面没有问题。 然后将 Glib 库中的 g_string_split 作为对应项，它很大程度上依赖于内存分配，就像基于 glib 或 GObject 的程序中的几乎所有内容一样。 可以肯定地说，在更动态的语言中，内存分配的使用比在更不灵活的语言中要多得多，尤其是 C。但让我们看看替代方案。 如果内存不足而结束程序，那么即使是精心开发的代码也可能会停止工作。 但如果您有可恢复的错误，您可以采取一些措施。 因此，使其可恢复的论点意味着人们可以选择以不同的方式“处理”这种情况（例如，为紧急情况留出一个内存块，或者降级为内存占用较少的程序）。

那么最有说服力的理由就是。 如果您提供一种恢复方法，可以尝试恢复，如果您没有选择，则一切都取决于始终获得足够的内存...

问候

Answer 20

现在我很困惑。

在工作中，我们有一堆应用程序一起工作，而内存不足。 虽然问题是要么使应用程序包成为 64 位（因此，能够超出我们在普通 Win32 操作系统上的 2 个 Go 限制），和/或减少内存的使用，但“如何从 OOM 中恢复”一直困扰着我。

当然，我没有解决方案，但仍然尝试为 C++ 寻找一个解决方案（主要是因为 RAII 和异常）。

也许一个应该正常恢复的进程应该将其处理分解为原子/可回滚任务（即仅使用提供强/不抛出异常保证的函数/方法），并保留用于恢复目的的“内存缓冲区/池”。

如果其中一项任务失败，C++ bad_alloc 将展开堆栈，通过 RAII 释放一些堆栈/堆内存。 然后，恢复功能将尽可能多地进行挽救（将任务的初始数据保存在磁盘上，以供以后尝试使用），并且可能注册任务数据以供以后尝试。

我确实相信使用 C++ 强/无抛出保证可以帮助进程在低可用内存条件下生存，即使它类似于内存交换（即缓慢、有些无响应等），但当然，这是只是理论。 在尝试模拟这个之前，我只需要在这个主题上变得更聪明（即创建一个 C++ 程序，使用内存有限的自定义 new/delete 分配器，然后尝试在这些压力条件下做一些工作）。

出色地...

Answer 21

内存不足通常意味着您必须放弃正在做的事情。 不过，如果您小心清理，它可以使程序本身保持运行并能够响应其他请求。 让程序说“抱歉，内存不足，无法执行”比说“抱歉，内存不足，正在关闭”要好。

Answer 22

内存不足可能是由于可用内存耗尽或尝试分配不合理的大块（例如一个演出）引起的。 在“耗尽”情况下，内存短缺对系统来说是全局性的，通常会影响其他应用程序和系统服务，并且整个系统可能会变得不稳定，因此明智的做法是忘记并重新启动。 在“不合理的大块”情况下，实际上不会发生短缺，并且可以安全地继续。 问题是您无法自动检测您所处的情况。因此，更安全的做法是使错误不可恢复，并为遇到此错误的每种情况找到解决方法 - 让您的程序使用更少的内存，或者在某些情况下只需修复调用内存分配的代码中的错误。

Answer 23

这里已经有很多好的答案了。 但我想从另一个角度做出贡献。

几乎任何可重复使用的资源的耗尽一般都应该是可以恢复的。 原因是程序的每个部分基本上都是子程序。 仅仅因为一个子程序在这一时间点无法完成它的结束，并不意味着程序的整个状态都是垃圾。 仅仅因为停车场停满了汽车并不意味着您就扔掉了您的汽车。 您要么等待一段时间等待有空位，要么开车到更远的商店购买饼干。

在大多数情况下，还有另一种方法。 使错误变得不可恢复，实际上会消除很多选择，而且我们都不喜欢让任何人来决定我们能做什么和不能做什么。

这同样适用于磁盘空间。 确实是同一个道理。 与您关于堆栈溢出是不可恢复的暗示相反，我想说这是任意限制。 没有充分的理由表明您不应该抛出异常（弹出大量帧），然后使用另一种效率较低的方法来完成工作。

我的两分钱:-)

Answer 24

如果你真的失去了记忆，你就注定失败，因为你无法再释放任何东西了。

如果你的内存不足，但是像垃圾收集器这样的东西可以启动并释放一些内存，那么你还没有死。

另一个问题是碎片化。 尽管您可能没有内存不足（碎片），但您可能仍然无法分配您想要的大块内存。