c# - MemoryFailPoint 始终抛出 InsufficientMemoryException，即使内存可用也是如此

Question

我写了下面的代码来检查内存是否充足，

while (true)
{
    try
    {
        // Check for available memory.
        memFailPoint = new MemoryFailPoint(250);

        break;
    }
    catch (InsufficientMemoryException ex)
    {
        if (memFailPoint != null)
        {
          memFailPoint.Dispose();
        }

        Thread.Sleep(waitSecond * 1000);
    }
}

我在 Windows 7 64 位计算机上的控制台应用程序中运行上述内容。

此方法每 10 秒调用 4 次。

最初它工作正常，但在 2-3 小时后，总是抛出 InsufficientMemoryException。我检查了可用内存，它显示超过 1 GB。

我尝试了很多，但无法找到发生这种情况的原因。

以下是堆栈跟踪:

at System.Runtime.MemoryFailPoint..ctor(Int32 sizeInMegabytes)
at SocketListner.AcceptConnection(IAsyncResult res) in H:\Projects\SocketListner.cs:line 308

没有内部异常。

Answer 1

您可以依赖此方法正常工作，当您请求 250 兆字节时，此异常非常可能会在 32 位进程中出错。当程序运行了一段时间后，这就变得很难了。

程序永远不会因 OOM 而崩溃，因为您已经消耗了所有可用的虚拟内存地址空间。它崩溃是因为地址空间中没有足够大的空洞来适应分配。您的代码请求一个大到足以一次性分配 250 兆字节的空洞。当你没有得到异常时，你可以确定这个分配不会失败。

但是 250 兆字节相当多，这是一个非常大的数组。并且很可能由于称为“地址空间碎片”的问题而失败。换句话说，一个程序通常从几个非常大的漏洞开始，最大的漏洞大约有 600 兆字节。在为存储 .NET 运行时和非托管 Windows DLL 使用的代码和数据而进行的分配之间存在空洞。随着程序分配更多内存，这些空洞会变小。它可能会释放一些内存，但不会重现大洞。您通常会得到 两个 洞，大约是原始大小的一半，中间某处的分配将原始大洞一分为二。

这称为碎片化，分配和释放大量内存的 32 位进程最终会碎片化虚拟内存地址空间，因此一段时间后仍然可用的最大空洞会变小，大约90 兆字节是相当典型的。要求 250 兆字节几乎肯定会失败。您需要放低目标。

您无疑希望它以不同的方式工作，确保分配的总和加起来达到 250 MB 保证工作。然而，这不是 MemoryFailPoint 的工作方式，它只检查最大 可能的分配。毋庸置疑，这可能会使它变得不那么有用。否则我很同情 .NET 框架程序员，让它按照我们希望的方式工作既昂贵又实际上不能提供保证，因为分配的大小最重要。

虚拟内存是一种非常便宜的丰富资源。但是要接近全部消耗掉就很麻烦了。一旦您消耗了 1 GB 的数据，随机出现的 OOM 就开始变得可能了。不要忘记这个问题的简单修复，您正在运行 64 位操作系统。因此，只需将 EXE 平台目标更改为 AnyCPU 即可获得大量的虚拟地址空间。取决于操作系统版本，但 TB 是可能的。它仍然是碎片，但你已经不在乎了，洞很大。

最后但同样重要的是，在评论中可见，此问题与 RAM 无关。虚拟内存与您拥有多少 RAM 完全无关。将虚拟内存地址映射到 RAM 中的物理地址是操作系统的工作，它是动态进行的。访问内存位置可能会引发页面错误，操作系统将为该页面分配 RAM。反之亦然，当其他地方需要时，操作系统会取消页面的 RAM 映射。你永远不会用完内存，机器会在这发生之前慢下来。 SysInternals 的 VMMap 实用程序很适合查看程序的虚拟地址空间，尽管您往往会淹没在大型进程的信息中。