c# - 如何使用 MemoryFailPoint？

Question

A MemoryFailPoint (MSDN) “在执行操作之前检查是否有足够的内存资源。”

但它究竟是如何正确使用的呢？

MemoryFailPoint 是否会自动为我创建的下一个大对象保留一些内存？或者它只是检查内存是否空闲，而不保留它？

它会检查物理内存、物理内存加页面文件、虚拟地址空间，还是完全检查其他内容？

我什么时候处理它？我是否需要在实际创建需要大量内存的对象之前处理 MemoryFailPoint，还是必须在处理 MemoryFailPoint 之前创建对象？

例如

try
{
   using (MemoryFailPoint mem = new MemoryFailPoint(500))
   {
      // allocate big object here?
   }
}
catch (InsufficientMemoryException e)
{
   // ...
}
// or allocate big object here?

// or allocate big object on another thread?

同一进程中的另一个线程是否可以窃取我使用 MemoryFailPoint 保留的内存，或者 MemoryFailPoint 是否专门为当前线程保留内存？

如果 MemoryFailPoint 没有被释放会怎样？未处置的 MemoryFailPoint 本身是否会消耗大量内存？

Answer 1

MemoryFailPoint 的源代码位于 .NET Source。 .类(class)开始时非常详细的评论回答了您的问题。我在此处复制该评论以便于引用:

This class allows an application to fail before starting certain activities. The idea is to fail early instead of failing in the middle of some long-running operation to increase the survivability of the application and ensure you don't have to write tricky code to handle an OOM anywhere in your app's code (which implies state corruption, meaning you should unload the appdomain, if you have a transacted environment to ensure rollback of individual transactions). This is an incomplete tool to attempt hoisting all your OOM failures from anywhere in your worker methods to one particular point where it is easier to handle an OOM failure, and you can optionally choose to not start a workitem if it will likely fail. This does not help the performance of your code directly (other than helping to avoid AD unloads). The point is to avoid starting work if it is likely to fail.
The Enterprise Services team has used these memory gates effectively in the unmanaged world for a decade.

In Whidbey, we will simply check to see if there is enough memory available in the OS's page file & attempt to ensure there might be enough space free within the process's address space (checking for address space fragmentation as well). We will not commit or reserve any memory. To avoid ----s with other threads using MemoryFailPoints, we'll also keep track of a process-wide amount of memory "reserved" via all currently-active MemoryFailPoints. This has two problems:

 1. This can account for memory twice.  If a thread creates a 
     MemoryFailPoint for 100 MB then allocates 99 MB, we'll see 99 MB 
     less free memory and 100 MB less reserved memory.  Yet, subtracting 
     off the 100 MB is necessary because the thread may not have started
     allocating memory yet.  Disposing of this class immediately after 
     front-loaded allocations have completed is a great idea.
 2. This is still vulnerable to ----s with other threads that don't use 
     MemoryFailPoints.

So this class is far from perfect. But it may be good enough to meaningfully reduce the frequency of OutOfMemoryExceptions in managed apps.

In Orcas or later, we might allocate some memory from the OS and add it to a allocation context for this thread. Obviously, at that point we need some way of conveying when we release this block of memory. So, we implemented IDisposable on this type in Whidbey and expect all users to call this from within a using block to provide lexical scope for their memory usage. The call to Dispose (implicit with the using block) will give us an opportunity to release this memory, perhaps. We anticipate this will give us the possibility of a more effective design in a future version.

In Orcas, we may also need to differentiate between allocations that would go into the normal managed heap vs. the large object heap, or we should consider checking for enough free space in both locations (with any appropriate adjustments to ensure the memory is contiguous).