GC.GetTotalMemory()包含哪些开发者无法控制的内存开销？

核心结论 #

你观察到的110MB剩余内存占用不属于代码内存泄漏，是.NET运行时的正常内存保留行为，现有Profiler结果已经可以证明你的托管代码内存管理处于合理水平。

指标差异的根本原因 #

几个内存统计值和Profiler结果不匹配，本质是不同统计口径的差异：

• 你用.NET Memory Profiler看到的10MB，是真正被存活托管对象占用的内存大小，这部分才是和你代码直接相关的内存占用。
• GC.GetTotalMemory()返回的是托管堆的总已提交大小，包含了GC回收后保留的空闲内存段——GC不会在每次回收后立刻把所有空闲内存还给操作系统，而是会预留一部分内存段应对后续的对象分配，避免频繁向OS申请/释放内存产生的性能开销。你处理1GB级文件时，大对象堆（LOH）会申请大块内存段，这些段即使在对象被回收后，也会被GC暂时保留。
• Windows任务管理器、Process.GetCurrentProcess().PrivateMemorySize64、Process.GetCurrentProcess().WorkingSet64统计的是进程向OS申请的全部内存，除了托管堆，还包含运行时本身的原生内存占用：JIT编译后的机器码缓存、类型元数据、IO完成端口预留、WinForms依赖的GDI+/图形子系统内存、线程栈预留空间，这些内存都不受托管代码直接控制，也不会被GC回收。

关于运行时开销的说明 #

你提到的“运行时开销是否会达到百兆级别”是完全正常的：

• 空载的WinForms .NET 5应用，仅加载窗体、运行时基础组件、JIT编译基础类库代码，就会占用30-60MB的进程内存，这部分是固定的基础开销。
• 执行1GB级文件读写后，GC为大对象堆预留的空闲段通常会有40-60MB，加起来刚好落在你观测到的110MB区间，不存在异常的内存浪费。

注意事项 #

仅调用GC.Collect()不会强制GC把所有保留内存还给操作系统
默认的GC.Collect()调用不会触发大对象堆压缩，也不会执行空闲段归还逻辑。如果要尽可能触发内存归还，需要按顺序执行以下代码：

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect(generation: 2, mode: GCCollectionMode.Forced, blocking: true, compact: true);
GC.WaitForPendingFinalizers();
GC.Collect(generation: 2, mode: GCCollectionMode.Forced, blocking: true, compact: true);

即使执行完上述代码，运行时的基础内存占用也不会降到几MB的水平，属于正常现象。如果不手动触发强制回收，GC会在程序闲置一段时间后自动逐步释放空闲段，内存会慢慢回落到空载水平。

排查建议 #

既然Profiler已经确认全回收后托管存活对象仅10MB，你不需要继续在业务代码里排查内存泄漏问题，所有判断托管内存泄漏的场景，都以全回收后的存活对象大小为唯一依据，不要用任务管理器的数值做判断标准。

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