当前位置：首页 > news >正文

DotMemory系列：3. 堆碎片化引发的内存暴涨分析

news 2026/6/11 17:32:18

一：背景

1. 讲故事

前面两篇我们讲的都是通过挂引用根的方式导致的内存暴涨，在快速检测台上能够一眼就看出是什么类型的Type导致的，分析难度稍微较低，在真实的dump分析场景下，也会存在对象偏小而内存暴涨的情况，一般的新手会被这种场景搞懵逼，这篇就来分享这种奇葩的情况。

二：内存暴涨分析

1. 问题代码

为了方便演示，我们做这样的一个案例，现在的 .NET8 的SOH一个segment是 4M，所以我故意这么设计，分配3M的临时对象，然后再分配一个 50k 的Pinned对象，由于 Pinned 解封之前是GC不可移动对象，最终会导致堆碎片化现象，参考代码如下：

internal class Program{static void Main(string[] args){var harmony = new Harmony("com.example.gchandleallchook");harmony.PatchAll();ProcessData();Console.ReadLine();}static void ProcessData(){for (int i = 1; i <= 1000; i++){Allocate_Bytes(i);Allocate_Pinned(i);Console.WriteLine($"i={i} 次执行，3M byte[] 分配完毕，50k byte[] 分配完毕");}GC.Collect();Console.WriteLine("碎片化已形成，已强制执行GC，请观察托管堆！");}static void Allocate_Bytes(int i){//1k * 1024 * 3 = 3M (1个region)for (int j = 0; j < 1024 * 3; j++){var bytes = new byte[1024]; // 分配 3096 个 1k 的 byte[]}}static void Allocate_Pinned(int i){GCHandle.Alloc(new byte[1024 * 50], GCHandleType.Pinned); // 50k 的 pinned byte[]}}

代码有了之后，接下来就是用 dotMemory 把程序给跑起来，内存走势图如下所示。

从卦中可以看到，内存总计为 1.9G，其中 gen2 就独吃 1.8G，很显然这是托管内存泄露,接下来的操作就是采一个 snapshot，打开快速检测台，截图如下：

从检测台上看并没有看到哪一个类型的对象有占用过大的情况，这是不是让人匪夷所思呢？

2. 为什么对象占用不大

虽然对象占用不大，但内存确确实实被托管堆的gen2所吃，所以必须调转枪头直接观测检测台的尾部 Heap Fragmentation 区域，截图如下：

哈哈，一下子就发现了 gen2 区域的奇观，即使看不懂的话也会觉得奇奇怪怪的，接下来我就简单分析下这里面的几个指标吧。

heap: 表示当前有 810 个 segment 内存段
total: 表示当前 gen2 吃了 1.77G 内存。
used(pinned)：表示 1.77G 内存中，pinned 对象占了 48.8M 内存。
used(unpinned): 表示 1.77G 内存中未固定对象吃了 46.8k 内存。
free: 表示当前空闲块吃了 1.73G。

上面几个指标合起来就是说 gen2 用 1.77G 内存只装近 50M 的对象，这种奇葩现象就是所谓的 堆碎片化。

接下来就是要寻找这些 pinned 对象，他们到底是什么，为什么让 GC 痛苦不堪，可以选择 Generations 选项卡，双击其中任一个segment，截图如下：

打开面板之后发现都是 Byte[] 数组，通过 Similar retention 选项卡发现都是 Pinning handle ，即通过 GCHandleType.Pinned 固定的，截图如下

接下来的问题是这些 Byte[] 数组到底是被谁固定的？为什么不解开呢？

2. byte[] 是谁创建的

如果把这个问题搞定了，那所有的真相就会大白，那怎么做呢？一般来说有两种做法，第一种就是 full 采集模式，然后观察 byte[] 的调用栈即可，还有一种方式使用 harmony 注入的方式记录调用栈。这里都给大家介绍一下吧。

full 采集模式

首先要说的是 full 采集模式在真实环境下很难实行，因为它对程序的性能伤害太大了，这个在官方文档中也有所说明，截图如下：

最后选择 Start 按钮开始采集，按照前面所述的方式找到 byte[] 数组再选择 Back Traces 选项卡，可以清楚的看到是 Allocate_Pinned() 方法创建的。

刚才是通过 type 为依据寻找的调用栈，也可以找到具体的 byte[] 实例观察其 Create Stack Trace 选项，同样也能看到，截图如下：

刚才也说了，这种方式虽然可行，但不是第一手段，更合适做万不得已的备份方案，万一程序能受得了这么重的暴击呢？

harmony 注入

第二种方式就是脱离 dotmemory，采用一种 IL 注入的方式，原理非常简单，就是在 SDK 的 GCHandle.Alloc 内部增加日志，参考代码如下：


public static GCHandle Alloc(object? value, GCHandleType type)
{// prefix： todo...return new GCHandle(value, type);// postfix：todo...
}

在 postfix 中我们记录下调用 Alloc 方法的调用栈，这样是不是就真相大白了，完整的参考代码如下：

internal class Program{static void Main(string[] args){var harmony = new Harmony("com.example.gchandleallchook");harmony.PatchAll();ProcessData();Console.ReadLine();}static void ProcessData(){for (int i = 1; i <= 1000; i++){Allocate_Bytes(i);Allocate_Pinned(i);Console.WriteLine($"i={i} 次执行，3M byte[] 分配完毕，50k byte[] 分配完毕");}GC.Collect();Console.WriteLine("碎片化已形成，已强制执行GC，请观察托管堆！");}static void Allocate_Bytes(int i){//1k * 1024 * 3 = 3M (1个region)for (int j = 0; j < 1024 * 3; j++){var bytes = new byte[1024]; // 分配 3096 个 1k 的 byte[]}}static void Allocate_Pinned(int i){GCHandle.Alloc(new byte[1024 * 50], GCHandleType.Pinned); // 50k 的 pinned byte[]}}[HarmonyPatch(typeof(GCHandle), "Alloc", new Type[] { typeof(object), typeof(GCHandleType) })]public class GCHandleAllocHook{public static void Postfix(GCHandle __result, GCHandleType type){if (type == GCHandleType.Pinned){Console.WriteLine($"  - 句柄指针: 0x{GCHandle.ToIntPtr(__result).ToInt64():X}");Console.WriteLine($"  - 句柄类型: {type}");Console.WriteLine(Environment.StackTrace);}}}

最后运行程序，观察日志输出即可，截图如下：