一：背景

1. 讲故事

说实话本来是不想写这个系列的，因为我潜意识里觉得这款工具就像美图秀秀一样，拉低专业人士的档次，但奈何在训练营里我需要用到 dottrace 这款工具，而我向官方申请再续了一年免费的Pack套件也给我通过了，所以我觉得要对得起他们，得要写点什么，截图如下：

这几天我也仔细看了下DotMemory的文档，发现还是有一些可圈可点的地方，毕竟美图秀秀也有美图秀秀的闪光点，在某些场景下完全可以用 DotMemory 作为WinDbg出场的第一套关卡，想来想去我决定还是写5篇托管内存故障来演示下DotMemory的使用，也确实它的可视化做的非常好，那这篇就先从 终结队列积压 导致的内存暴涨开始吧。

二：内存暴涨分析

1. 问题代码

为了演示 终结队列积压 引发的内存暴涨，我故意让 终结器线程 处理的慢一些，这样就会存在不断的囤积情况，参考代码如下：

    internal class Program
    {
        static void Main(string[] args)
        {
            for (int i = 1; i < 500000; i++)
            {
                NewPerson(i);
            }
            Console.WriteLine("50w 个对象插入完毕！");
            Console.ReadLine();
        }

        static void NewPerson(int i)
        {
            var person = new Person()
            {
                ID = i + 1,
                Name = string.Join(",", Enumerable.Range(0, 1000))
            };
        }
    }

    public class Person
    {
        public int ID { get; set; }

        public string Name { get; set; }

        ~Person()
        {
            Thread.Sleep(1000);
            Console.WriteLine($"析构函数 {ID}: 执行完毕...");
        }
    }

2. DotMemory 分析

这里我用的是 DotMemory 2025.1 版本，用 dotmemory 开启子进程的方式启动，大概三步走就行了，截图如下：

这里一定要选择 Sampled 采样模式，如果选择 Full 模式那几乎是无法跑的，因为都是基于 ETW 的，所以和 perfview 的 .NET SampleAlloc 模式是一模一样的。

点击 Start 后，会有一个内存用量的动态图，在内存出现暴涨后，使用 Get Snapshot 采一个快照下来，截图如下：

打开图中左下角的 Snapshot #1 快照，映入眼帘的就是 Inspections 视图，翻译过来用 检测台 比较合适，截图如下：

稍微熟悉 DotMemory 的朋友，看到快速通览之后肯定会发现问题所在，我就单独开一节来说吧！

3. 问题浮现

1. Largest Size 环形图

这个图是告诉大家某一类对象的浅层大小，即不包含他们的孩子节点，用 windbg 的话术就是直接取Person自身的 Size=32byte，很显然这 32byte 是不包含 Person.<Name>k__BackingField 的 Size=7800byte 的，输出如下：

0:015> !dumpobj /d 2e9693a2fa0
Name:        Example_20_1_1.Person
MethodTable: 00007ffa0b5fa898
EEClass:     00007ffa0b6046a8
Tracked Type: false
Size:        32(0x20) bytes
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffa0b4b1188  4000001       10         System.Int32  1 instance            23906 <ID>k__BackingField
00007ffa0b52ec08  4000002        8        System.String  0 instance 000002e9693a3000 <Name>k__BackingField

0:015> !DumpObj /d 000002e9693a3000
Name:        System.String
MethodTable: 00007ffa0b52ec08
EEClass:     00007ffa0b50a5d8
Tracked Type: false
Size:        7800(0x1e78) bytes
String:      0,1,2,3,...
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffa0b4b1188  400033b        8         System.Int32  1 instance             3889 _stringLength
00007ffa0b4bb538  400033c        c          System.Char  1 instance               30 _firstChar
00007ffa0b52ec08  400033a       c8        System.String  0   static 000002e900000008 Empty

有了上面的思路之后，你应该就知道这个程序中吃的最多的就是String类型，总计 3.63G，对 String 产生重大怀疑之后，接下来就是看第二个环形图。

2. Largest Retained Size 环形图

如果说刚才的图是不包含孩子节点的，那这张图就是切切实实的包含孩子节点，有些人可能要问，既然是包含关系，那包含的起点在哪里呢？熟悉 gc标记阶段的朋友应该知道，这个起点应该就是 root 根。

有了这个基础之后，你就应该能明白为什么 Person 类型的总量是排在第一位的，刚才的 windbg 输出已经告诉了我们，看样子 Person.<Name>k__BackingField 正是我们的问题所在。

3. String duplicates 问题

在内功修炼训练营里跟大家分享过 驻留池 的底层原理，其实这个就是和 驻留池 有关，从卦中可以看到由 49.9w 的字符串理应都要进池子，结果都是以副本的形式存在于托管堆中，所以这里有了 Wasted=3.63G 一说，哈哈，到这里又看到了一处非常不合理的地方，也就说如果把这 49.9w 的string全部进池子，那么内存一下子就下去了，等一会我们来验证吧。

4. Finalizable Objects 问题

这里有一个异常的信号，即 红色感叹号，说明这里可能存在一个大问题，从列表中可以看到 Person=49.9w，截图如下：

这里的 49.9w 表示什么呢？ 熟悉clr终结队列的朋友应该知道，这个 queued 其实就是 freachable queue 区域，即 终结器线程 提取对象的地方。

如果有些朋友还是搞不清楚，在我的训练营里有详细的画图说明，其中的 深绿色区域 就是所谓的提取区域，截图如下：

如果一定要在 dotmemory 上验证，那就双击呗，观察 Similar Retention 选项即可，截图如下：

言归正传，接下来的问题就来了，为什么 终结器队列 中有那么多的囤积？

4. 寻求问题之道

由于是采样模式，直接观察 CallTree 和 Back Traces 选项卡会不准，所以就直接观察 Person 的源代码，为什么 析构函数 这么不给力，很快就发现有不对的地方，这里居然有慢处理 Thread.Sleep(1000)，参考如下：

        ~Person()
        {
            Thread.Sleep(1000);
            Console.WriteLine($"析构函数 {ID}: 执行完毕...");
        }

这里稍微提醒一下，在真实场景中，一般会用 windbg 去观察此时的 终结器线程 的调用栈，但无奈 dotmemory 不具备观察线程的调用栈能力。

所以解决办法就比较简单了，将 Thread.Sleep(1000); 注释掉即可。

最后再说一种办法，也就是刚才说到了 wasted，如果全部送到驻留池，其实也是治标不治本的方法，但在这种场景下可以绝对的延迟OOM的时间，即用 string.Intern 给包起来，参考代码如下：

        static void NewPerson(int i)
        {
            var person = new Person()
            {
                ID = i + 1,
                Name = string.Intern(string.Join(",", Enumerable.Range(0, 1000)))
            };
        }

从卦中可以看到，其实送入了 50w 的超大 string，因为内存中只保有一份，所以再怎么大也大不起来，从检测台上也能看到那玩意在 String duplicates 列表中消失了，截图如下：

三：总结

DotMemory虽为美图秀秀，但秀秀也有秀秀的场景，在进一步深度分析之前，它是一款很好的快速通览利器。