我可能在这里编辑了一点,但是使用虚拟/逻辑内存的现代趋势(这两个名称都已使用,尽管“逻辑”更明显)确实使知道内存何时耗尽变得非常复杂,尽管我认为可以恢复Linux 中旧的、真实的(RAM + 交换)模型(我将其称为物理模型),其中包含以下内容/etc/sysctl.d/10-no-overcommit.conf:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
这恢复了这样一种哲学的能力,即如果一个程序malloc刚刚失败,该程序很有可能是内存耗尽的真正原因,然后可以退出当前对象的构造,free一路上内存,可能会抱怨用户要求了一些需要太多 RAM 的疯狂东西,并等待下一个请求。在此模型中,大多数 OOM 条件几乎立即解决 - 程序要么应对并可能返回 RAM,要么在尝试使用由malloc.
使用 linux 在 2013 年默认使用的虚拟/逻辑内存模型,这不起作用,因为程序不会发现内存不可用malloc,而是在稍后尝试访问内存时内核最终意识到 RAM 中没有它的位置。这相当于一场灾难,因为系统上的任何程序都可能死掉,而不是主机内存不足的那个。人们可以理解为什么有些 GLib 的人甚至不关心尝试解决这个问题,因为使用逻辑内存模型,它无法修复。
逻辑内存的初衷是允许使用主机一半以上内存的大型程序仍然能够 fork 和 exec 支持程序。它通常仅在具有该特定使用模式的主机上启用。现在在 2013 年,当家庭工作站可以拥有 24+ GiB 的 RAM 时,真的没有任何借口可以在 99% 的时间内启用逻辑内存。默认情况下,它应该在启动时具有 >4 GiB RAM 的主机上被禁用。
反正。因此,如果您想采用老式物理模型方法,请确保您的计算机已启用它,否则测试您的malloc和realloc调用毫无意义。
如果您处于该模型中,请记住 GLib 并没有真正遵循相同的理念(请参阅http://code.google.com/p/chromium/issues/detail?id=51286#c27了解一些人多么疯狂地误入歧途其中是)。任何基于 GLib 的库也可能被同样的态度感染。但是,通过在物理内存模型中使用 GLib 放置您自己的内存处理程序g_mem_set_vtable(),您可能会做一些有趣的事情,然后重试底层malloc。但是,由于在调用您的特殊处理程序时不知道正在构建哪个对象,这有其自身的限制。