调试C#控制台程序时进程内存增长，但内存快照无差异的问题

我编写了如下C#控制台程序：

using System;
using System.Threading.Tasks;
namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            Task[] t = { Run() };
            Task.WaitAll(t);
            Console.ReadLine();
        }
        private static async Task Run()
        {
            Console.WriteLine($"Running");
            await Task.Delay(100);
            Run();
        }
    }
}

在调试该程序时，我发现Process Memory（MB）的监控图表显示内存略有增长，但拍摄内存快照后，却未观测到内存使用情况存在差异，请问这一现象的原因是什么？

这是个很常见的内存监控与快照认知差异问题，咱们一步步拆解清楚：

1. 你的异步递归代码的内存行为 #

首先，Run()是一个无限循环的异步递归方法——每次await Task.Delay(100)完成后，都会再次调用Run()。这里要注意一个关键点：每一次调用异步方法时，.NET都会自动生成一个状态机实例（比如编译器会生成类似<Run>d__0的隐藏类），同时还会创建新的Task对象。这些对象在被垃圾回收（GC）处理前，会暂时占用托管堆的内存空间。

2. Process Memory 和内存快照的核心区别 #

你看到的Process Memory（进程内存）监控，其实是操作系统统计的进程工作集（Working Set），它的范围要比托管堆大得多：

• 包含托管堆里的所有对象（包括存活对象和已经标记为待回收的垃圾）
• 包含非托管内存的分配（比如操作系统API调用的内存）
• 包含操作系统为进程缓存的页面、线程栈等临时内存块
• 甚至包含那些已经成为垃圾，但还没被GC回收的对象

而内存快照（通常指托管堆快照）只会抓取当前处于存活状态的托管对象——也就是那些还被根引用链指向、不会被GC回收的对象。更重要的是，很多调试工具在拍摄内存快照前，会自动触发一次强制GC，把所有待回收的垃圾对象清理掉，这时候快照里自然看不到内存增长的痕迹。

3. 对应到你的程序场景 #

你的无限递归会不断生成新的状态机和Task对象，但这些对象其实没有被长期引用：每次Run()的状态机在await完成后，除了回调里的新Run()调用，没有其他代码持有它的引用。所以这些对象都是短期存活的垃圾，会被Gen0级别的GC快速回收。

但GC不是实时运行的——它会等到Gen0堆的内存占用达到阈值时才触发。在GC触发前，这些垃圾对象会暂时留在托管堆里，导致进程工作集的数值上升。而当你拍摄内存快照时，要么工具自动触发了GC清理了垃圾，要么快照本身只统计存活对象，所以你看不到内存使用的差异。

另外，操作系统的内存管理策略也可能推高这个数值：当系统内存充足时，操作系统不会主动回收进程的缓存页面，这也会让监控图表显示内存上升，但实际托管堆的存活对象并没有增加。

总结一下：监控到的内存增长是临时的垃圾对象或操作系统层面的内存缓存，而内存快照只关注存活的托管对象，所以两者出现了差异。

内容的提问来源于stack exchange，提问作者Mike