Linux 乐观 malloc：当内存不足时，new 总会抛出吗？

问题描述：

我一直在阅读有关 Linux 上内存不足的情况，手册页中的以下段落引起了我的思考：

默认情况下，Linux 遵循乐观内存分配策略。这意味着当 malloc() 返回非 NULL 时，无法保证内存确实可用。这是一个非常严重的错误。如果系统内存不足，一个或多个进程将被臭名昭著的 OOM 杀手杀死。[...]

考虑到运算符 new 实现最终会在某个时候调用 malloc，是否有任何保证表明 new 确实会在 Linux 上抛出错误？如果没有，如何处理这种显然无法检测到的错误情况？

解决方案 1：

这取决于情况；您可以使用 vm.overcommit_memory 配置内核的过度提交设置。

几年前，Herb Sutter 讨论过这种行为实际上不符合 C++ 标准：

“在某些操作系统上，特别是 Linux，内存分配总是会成功。句号。即使请求的内存实际上不可用，分配怎么可能总是成功？原因是分配本身仅记录对内存的请求；在幕后，（物理或虚拟）内存实际上并没有提交给请求进程，也没有真正的后备存储，直到内存被实际使用。

“请注意，如果 new 直接使用操作系统的功能，那么 new 将始终成功，但任何后续的无害代码（如 buf[100] = 'c';）都可能抛出异常、失败或停止。从标准 C++ 的角度来看，这两种效果都是不符合要求的，因为 C++ 标准要求，如果 new 无法提交足够的内存，它就必须失败（但这并不会发生），并且像 buf[100] = 'c' 这样的代码不应抛出异常或以其他方式失败（这可能会发生）。”

解决方案 2：

简单来说，你无法通过软件来处理它。

对于您的应用程序，您将收到一个完全有效的指针。一旦您尝试访问它，它将在内核中生成页面错误，内核将尝试为其分配物理页面，如果不能...就完了。

但正如您所看到的，所有这些都发生在内核中，您的应用程序无法看到。如果这是一个关键系统，您可以在系统上完全禁用过量提交。

解决方案 3：

我认为 malloc 仍然可以返回 NULL。原因是系统可用内存（RAM + swap）与进程地址空间中的数量存在差异。

例如，如果您在标准 x86 Linux 上从 malloc 申请 3GB 内存，它肯定会返回 NULL，因为考虑到分配给用户空间应用程序的内存量，这是不可能的。

解决方案 4：

如果我错了请原谅我，但尝试将分配的内存清零是否足以保证您拥有所请求的每个字节？或者即使只是写入最后一个字节，如果内存不是您的，它也会引发异常，对吗？

如果这是真的，您可以尝试写入内存的最后一个（和第一个？）字节，看看它是否正常工作，如果不行，您可以从 malloc 返回 null。

解决方案 5：

是的，有一点可以保证，new 最终会抛出异常。无论是否过度使用，地址空间都是有限的。因此，如果你继续分配内存，迟早会用尽地址空间，new 将被迫抛出异常。