PerfView 洞察 C#托管堆内存 "黑洞现象"

一：背景

1. 讲故事

首先声明的是这个黑洞是我定义的术语，它是用来表示内存吞噬的一种现象，何为内存吞噬，我们来看一张图。

创新互联建站服务项目包括全州网站建设、全州网站制作、全州网页制作以及全州网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，全州网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到全州省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

图片

从上面的卦象图来看，GCHeap 的 Allocated=852M 和 Committed=16.6G，它们的差值就是分配缓冲区=16G，缓冲区的好处就是用空间换时间，弊端就是会实实在在的侵占内存，挤压其他程序的生存空间。

二：黑洞现象

1. 为什么会有黑洞现象

万事皆有因果，今生的果是前世种的因，换句话说是程序曾经有大量及频繁的创建临时对象，让GC不自主的痉挛，小挛伤神，大挛伤身，所以GC为了避免大挛的发生，就大量的囤积本应该释放掉的内存，目的就是防止未来某个时刻再次有大内存分配的发生。

2. 重现今生的果

我相信因果关系大家都弄清楚了，但口说无凭，还得用代码证明一下不是？为了模拟GC痉挛，上一段测试代码。

public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.
            builder.Services.AddAuthorization();
            var app = builder.Build();

            // Configure the HTTP request pipeline.
            app.UseAuthorization();

            app.MapGet("/mytest", (HttpContext httpContext) =>
            {
                return MyTest();
            });

            app.MapGet("/gc", (HttpContext httpContext) =>
            {
                GC.Collect();

                return 1;
            });

            app.Run();
        }

        public static string MyTest()
        {
            List list = new List();

            for (int i = 0; i < 100000000; i++)
            {
                list.Add(i.ToString());
            }

            return "ok";
        }
    }

代码非常简单，每请求一次 /mytest 都会分配一个 1亿大小 List 数组，而这个 List 又是一个临时对象，后续会被 GC 回收，接下来我们多请求几次来调戏一下 GC，看他如何痉挛，截图如下：

图片

从卦中看，我当前请求了 6 次，内存峰值达到了 12G，因为是临时对象，稍稍有一点回落，但此时已经撑成一个大胖子了，接下来我们用 WinDbg 附加一下，观察下 Allocated 和 Committed 阈值。

0:033> !eeheap -gc

========================================
Number of GC Heaps: 12
----------------------------------------
...
Heap 11 (0000023513f26c10)
generation 0 starts at 23351c3aab8
generation 1 starts at 233484c38e0
generation 2 starts at 233484c1000
ephemeral segment allocation context: none
Small object heap
         segment            begin        allocated        committed allocated size          committed size         
    0233484c0000     0233484c1000     02335c794ad0     023379ad2000 0x142d3ad0 (338508496)  0x31612000 (828448768) 
Large object heap starts at 234384c1000
         segment            begin        allocated        committed allocated size          committed size         
    0234384c0000     0234384c1000     0234384c1018     0234384e2000 0x18 (24)               0x22000 (139264)       
Pinned object heap starts at 234f84c1000
         segment            begin        allocated        committed allocated size          committed size         
    0234f84c0000     0234f84c1000     0234f84c1018     0234f84c2000 0x18 (24)               0x2000 (8192)          
------------------------------
GC Allocated Heap Size:    Size: 0x14f241378 (5622731640) bytes.
GC Committed Heap Size:    Size: 0x2b125c000 (11561975808) bytes.

从卦中看当前已经有 6G 的缓冲区了，为了让缓冲区更夸张，我们故意手工触发一次 GC 即请求 /gc，触发了GC之后，内存从 10G 回落到了 7G 就不再降了，截图如下：

图片

从卦中看，这两个指标就更夸张了，GC 堆只有 1.1M 的对象，但预留了 7.1G 的内存。

这个GC表现不管在道德还是伦理上都说不通的。

3. 找到前世的因

要想找到前世的因，手段有很多，比如用 WinDbg 观察前世的托管堆，从残留的 Committed - Allocated上就能找到因，也可以使用 PerfView 实时观察，这里我们采用后者来洞察，使用默认的 Command 参数。

PerfView.exe  "/DataFile:PerfViewData.etl" /BufferSizeMB:256 /StackCompression /CircularMB:500 /ClrEvents:GC,Binder,Security,AppDomainResourceManagement,Contention,Exception,Threading,JITSymbols,Type,GCHeapSurvivalAndMovement,GCHeapAndTypeNames,Stack,ThreadTransfer,Codesymbols,Compilation /NoGui /NoNGenRundown /Merge:True /Zip:True collect

采集一段时间后停止采集，接下来双击 GC Heap Net Mem (Coarse Sampling) Stacks 选项再选择 WebApplication1 进程，通过 MaxMetric 指标看到曾经峰值达到了 10.9G，截图如下：

图片

毫无疑问的说，内存峰值的时候必有妖怪，可以将峰值填入到 End 文本框中，然后双击内存占比最高的 System.String[]，观察下它是谁分配的，截图如下：

图片

从截图中可以清晰的看到，原来是 Program.MyTest() 造的孽，至此真相大白。

4. 寻求化解之道

化解之道有很多：

修改 GC 模式

简而言之就是将 Server GC 改成 Workstation GC ，参考代码如下：



  
    false

修改 Heap 个数

默认情况一个 cpucore 有一个 heap，我们可以尽量的减少 heap.count 的个数，比如将 12 个改成 2 个。参考代码如下：

{
   "runtimeOptions": {
      "configProperties": {
         "System.GC.HeapCount": 2
      }
   }
}

大事化小

导致今世的果是因为在内存中短时的出现大对象，可以将大对象拆分成多批次的小对象处理，这样可以达到后浪推前浪的的内存复用，从源头上绕过这个问题。

三：总结

内存黑洞虽不算 CLR 的一个bug，但绝对是 CLR 可优化的一个空间，分析这类问题是需要经验性的，分享出来供后来者少踩坑吧，毕竟在我的分析旅程中至少遇到了3次。

名称栏目：PerfView 洞察 C#托管堆内存 "黑洞现象"
地址分享：http://www.shufengxianlan.com/qtweb/news44/168694.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容