.NET Framework与.NET Core虚拟内存占用差异原因及准确性咨询

问题场景 #

将基于.NET Framework 3.5的项目升级至.NET 7后，使用如下代码监控进程内存时，发现PeakVirtualMemorySize64数值差异巨大：

static void Main(string[] args)
{
    var process = Process.GetCurrentProcess();
    Console.WriteLine(FormatSize(process.PeakVirtualMemorySize64));
    Console.WriteLine(FormatSize(process.PeakWorkingSet64));
    Console.Read();
}

public static string FormatSize(long size)
{
    string[] units = { "bytes", "KB", "MB", "GB", "TB" };
    double s = size;
    int index = 0;

    while (s > 1024 && index++ < units.Length - 1)
    {
        s /= 1024d;
    }

    return $"{s:.00} {units[index]}";
}

运行结果对比：

• .NET Framework 4.8：峰值虚拟内存4.54 GB、工作集23.07 MB
• .NET 7.0：峰值虚拟内存2.3 TB、工作集21.91 MB

峰值虚拟内存差异的原因 #

• 虚拟地址空间策略不同：.NET 7默认启用Large Address Aware特性，64位系统下进程虚拟地址空间上限远高于.NET Framework；同时CoreCLR运行时会预先保留大量虚拟内存区域用于后续分配，这些保留的地址空间并未实际占用物理内存，但会被计入PeakVirtualMemorySize64。
• GC内存管理策略差异：.NET 7的垃圾回收机制为大对象堆（LOH）、托管堆等预先保留更大的虚拟内存块，以减少分配时的碎片化问题，这直接推高了峰值虚拟内存的统计值。
• .NET Framework的保守分配：.NET Framework的内存分配策略偏向按需逐步提交虚拟内存，不会预先保留过大的地址空间，因此PeakVirtualMemorySize64数值更接近实际使用的虚拟内存量。

监控实际内存使用的推荐指标 #

如果要监控程序实际消耗的内存资源，优先选择以下更准确的指标：

• PrivateMemorySize64：进程私有的、未与其他进程共享的物理内存大小，能精准反映程序自身实际占用的物理内存，排除了系统共享库等外部内存占用。
• GC.GetTotalMemory(true)：这是.NET特有的内存监控方法，返回当前GC托管堆中已分配的内存总量（传入true会强制触发一次垃圾回收，得到更准确的当前内存使用量），完全聚焦于托管代码的内存消耗。
• WorkingSet64：进程当前加载到物理内存中的页面大小，包含共享内存页，数值略偏高，但能反映进程当前实际占用的物理内存总量（包括共享部分）。

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