DotMemory系列：4. 如何分析进程的转储文件

摘要：前面几篇文章说的都是对进程采集 snapshot 文件，但这种方式的前提需要在目标机器上运行DotMemory相关组件，这在很多生产环境下很难做到，我知道很多医疗，金融生产环境，部署一个外来文件都需要层层审批，尤其像 dotmemory 这种商业软件，想上去门

前面几篇文章说的都是对进程采集 snapshot 文件，但这种方式的前提需要在目标机器上运行DotMemory相关组件，这在很多生产环境下很难做到，我知道很多医疗，金融生产环境，部署一个外来文件都需要层层审批，尤其像 dotmemory 这种商业软件，想上去门到没有。。。

目前主流的做法就是生成dump文件拿到线下分析，如果 dotmemory 不集成这块生态，那就是自绝于天地，接下来我们就来一起研究下。

1. 测试代码

为了方便演示，我故意模拟一个内存分配的快进快出案例，即在一个方法内分配大量的临时对象，观察内存的上涨情况，参考代码如下：

internal classProgram
{
static void Main(string args)
{
ProcessMemoryAllocation;
Console.ReadLine;
}

static void ProcessMemoryAllocation
{
Console.WriteLine("开始分配内存...");

// 分配 100MB 数组
long bytes100MB = (long)100 * 1024 * 1024;
byte array100MB = newbyte[bytes100MB];
array100MB[0] = 0x01;
array100MB[array100MB.Length - 1] = 0xFF;
Console.WriteLine($"✓ 100MB 数组分配成功: {bytes100MB:N0} 字节");

// 分配 500MB 数组
long bytes500MB = (long)500 * 1024 * 1024;
byte array500MB = newbyte[bytes500MB];
array500MB[0] = 0x02;
array500MB[array500MB.Length - 1] = 0xFE;
Console.WriteLine($"✓ 500MB 数组分配成功: {bytes500MB:N0} 字节");

// 分配 1GB 数组
long bytes1GB = (long)1024 * 1024 * 1024;
byte array1GB = newbyte[bytes1GB];
array1GB[0] = 0x03;
array1GB[array1GB.Length - 1] = 0xFD;
Console.WriteLine($"✓ 1GB 数组分配成功: {bytes1GB:N0} 字节");

long totalBytes = bytes100MB + bytes500MB + bytes1GB;
Console.WriteLine($"分配完成！");
Console.WriteLine($"总计分配: {totalBytes:N0} 字节");
Console.WriteLine($"约 {totalBytes / (1024.0 * 1024.0):F2} MB");
Console.WriteLine($"约 {totalBytes / (1024.0 * 1024.0 * 1024.0):F2} GB");

}
}

程序运行起来之后，可以看到当前程序吃了 1.7G 的内存，接下来用 process explorer 抓一个dump，截图如下：

2. 使用 dotmemory 分析点击Import Process Dump按钮，找到要分析的文件，稍等之后就能看到快速检测台，这里要注意一下，dump文件越大，稍等的时间就越长，也可能等了几十分钟后结果爆了个内存不足，也是无语了，它的底层是通过一个单独的MemoryDumpConverter.exe程序来抽取托管堆数据的，截图如下：

由于程序吃了 1.7G，所以要观察下到底是谁吃掉了，观察Overview

从卦中可以看到 .NET 使用了1.59G内存，其中活对象是105k，看到这个数据很容易让人联想到上一篇说的碎片化问题，那到底是不是呢？3. 是堆碎片化吗进入Inspections视图，观察区域，发现LOH上的 free=1.59G，这就让人很无语了，截图如下：

既然整条的 segment 都是 free，为什么gc不在上一阶段完整的回收它呢？带着忐忑不安的心情发现是上图中有一串数字 1.59GB occupied by 76 unreachable objects，啊，，，原来是待回收的垃圾对象呀，但这个对象目前还不是 free 对象呀，为什么要把它当作 free 处理呢？这种处理方式和传统的 windbg 处理模式完全不一样，需要适应一样，哈哈。

接下来点击这 76 个不可达对象，可以看到是 3 个超大的 byte给吞掉了，截图如下：

dump 的单个分析我们差不多搞定了，接下来研究下双dump分析。

1. 测试代码

为了能够捕获内存增量，修改了一下代码，在增量的第一和第三阶段各采一个dump文件，分别为 100M+ 和 1.7G+，代码和截图如下：

static void ProcessMemoryAllocation
{
Console.WriteLine("开始分配内存...");

// 分配 100MB 数组
long bytes100MB = (long)100 * 1024 * 1024;
byte array100MB = newbyte[bytes100MB];
array100MB[0] = 0x01;
array100MB[array100MB.Length - 1] = 0xFF;
Console.WriteLine($"1. 100MB 数组分配成功: {bytes100MB:N0} 字节");

Thread.Sleep(5000);

// 分配 500MB 数组
long bytes500MB = (long)500 * 1024 * 1024;
byte array500MB = newbyte[bytes500MB];
array500MB[0] = 0x02;
array500MB[array500MB.Length - 1] = 0xFE;
Console.WriteLine($"2. 500MB 数组分配成功: {bytes500MB:N0} 字节");

Thread.Sleep(5000);

// 分配 1GB 数组
long bytes1GB = (long)1024 * 1024 * 1024;
byte array1GB = newbyte[bytes1GB];
array1GB[0] = 0x03;
array1GB[array1GB.Length - 1] = 0xFD;
Console.WriteLine($"3. 1GB 数组分配成功: {bytes1GB:N0} 字节");

Thread.Sleep(5000);

long totalBytes = bytes100MB + bytes500MB + bytes1GB;
Console.WriteLine($"分配完成！");
Console.WriteLine($"总计分配: {totalBytes:N0} 字节");
Console.WriteLine($"约 {totalBytes / (1024.0 * 1024.0):F2} MB");
Console.WriteLine($"约 {totalBytes / (1024.0 * 1024.0 * 1024.0):F2} GB");

Console.ReadLine;
}

这两个dump都有了，如何比较增量呢? 做法比较简单，先将两个 dump 分别导入到 workspace 中，然后随意在一个 overview 中选择Compare with snapshot from another workspace，即跨工作区比较，截图如下：