即使内存可用，MemoryFailPoint 也总是抛出 InsufficientMemoryException答案

【问题标题】：MemoryFailPoint always throws an InsufficientMemoryException even when memory is available即使内存可用，MemoryFailPoint 也总是抛出 InsufficientMemoryException
【发布时间】：2013-06-07 10:36:09
【问题描述】：

我已经编写了以下代码来检查是否有足够的内存，

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

没有内部异常。

【问题讨论】：

你还在做什么来得到这个错误？您可以发布堆栈跟踪吗？
我已添加堆栈跟踪，请重新访问问题
“我检查了可用内存”如何？即使有 1GB 的空闲空间，它也可能过于分散而无法分配 250Meg。内存中需要有 250M 的连续可用空间才能成功。
剩下多少物理内存甚至虚拟内存都没有关系。您的进程使用了多少内存？
我检查了资源监视器

标签： c# memory-management memory-leaks out-of-memory

【解决方案1】：

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

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

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

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

毫无疑问，您希望它以不同的方式工作，以确保总计 250 兆字节的分配总和可以正常工作。然而，这不是 MemoryFailPoint 的工作方式，它只检查最大可能的分配。或许不用说，这使得它没有用处。否则，我确实同情 .NET 框架程序员，让它以我们希望的方式工作既昂贵又实际上不能提供保证，因为分配的大小最重要。

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

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

【讨论】：

感谢您的详细分析和建议。我已将大小减小到 50MB 并将应用程序置于测试中，但是我在 64 位中进行了构建，因此不应该发生 OOM 异常，因为它是之前被捕获的。
我不得不说，随便把它从 250 削减到 50 是相当随机的。重要的是，您选择的数字具有一定的真实性并代表您将需要的内存量。
怎么知道？，一旦数据包被处理，内存应该是空闲的，但是在很长一段时间后数据库成为瓶颈并且数据在内存中停留到超时，即 30 秒。
如果您不知道，那么使用内存分析器收集证据很重要。我提到的 VMMap 实用程序是一个便宜的版本。尝试传递给 MemoryFailPoint 的值是很长的路要走。

【解决方案2】：

MemoryFailPoint 检查连续可用内存，如下所述：http://msdn.microsoft.com/fr-fr/library/system.runtime.memoryfailpoint.aspx

您可能会消耗很少的内存，但已经将它分成很多块，然后现在无法分配所需大小的连续内存块。几个小时后发生此问题是非常典型的。为避免这种情况，请为您不断实例化的对象使用对象池，这会使使用中的内存空间更加僵化。

【讨论】：

【解决方案3】：

考虑使用GC.GetTotalMemory 方法来确定调用前后的可用内存量：

memFailPoint = new MemoryFailPoint(250);

InsufficientMemoryException 在开始操作之前由MemoryFailPoint 构造函数在您指定大于当前可用内存量的预计内存分配时抛出。像 user7116 commented，这就是为什么你应该先检查。

此链接中的示例应该为您提供解决方案：MemoryFailPoint Class

您也可以查看这篇 msdn 博客文章：Out of memory? Easy ways to increase the memory available to your program

【讨论】：