PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏

  • PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏已关闭评论
  • 30 次浏览
  • A+
所属分类:.NET技术
摘要

前两篇我们都聊到了非托管内存泄漏,一个是 HeapAlloc ,一个是 VirtualAlloc,除了这两种泄漏之外还存在其他渠道的内存泄漏,比如程序集泄漏,这一篇我们就来聊一聊。


一:背景

前两篇我们都聊到了非托管内存泄漏,一个是 HeapAlloc ,一个是 VirtualAlloc,除了这两种泄漏之外还存在其他渠道的内存泄漏,比如程序集泄漏,这一篇我们就来聊一聊。

二: 程序集也会泄漏?

在我分析的一百多dump中,程序集方面的泄漏主要有 XmlSerializerCastle.Proxy 这两个入口,这里就来探讨 XmlSerializer 所造成的泄漏。

1. 问题代码

为了方便讲述,先上一段测试代码,百分百内存泄漏,如假包换。

     internal class Program     {         static void Main(string[] args)         {             var xml = @" <FabrikamCustomer>                               <Id>0001</Id>                               <FirstName>John</FirstName>                               <LastName>Dow</LastName>                           </FabrikamCustomer>";              Enumerable.Range(0, 30000)                  .Select(i => GetCustomer(i, "FabrikamCustomer", xml))                  .ToList();              Console.WriteLine("处理完成!");             Console.ReadLine();         }         public static Customer GetCustomer(int i, string rootElementName, string xml)         {             var xmlSerializer = new XmlSerializer(typeof(Customer),                             new XmlRootAttribute(rootElementName));              using (var textReader = new StringReader(xml))             {                 using (var xmlReader = XmlReader.Create(textReader))                 {                     Console.WriteLine(i);                      return (Customer)xmlSerializer.Deserialize(xmlReader);                 }             }          }     }     public class Customer     {         public string Id { get; set; }         public string FirstName { get; set; }         public string LastName { get; set; }     }  

故意让程序调用 XmlSerializer 三万次,跑完后我们看一下内存占用情况。

PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏

从图中你会观察到,内存会一直往上飙,直到 1.35G 为止,很明显这么简单的代码会有这么大的内存占用,已经超出了我的预期,接下来用 windbg 探究下到底怎么回事?

2. windbg 调试

既然内存泄漏了,我们需要用 windbg 研判下到底是哪方面的内存泄漏,托管层还好说,如果是非托管 那又是头大的事。。。 先用 !address -summary 观察下。

 0:000> !heap -s   ************************************************************************************************************************                                               NT HEAP STATS BELOW ************************************************************************************************************************ LFH Key                   : 0x14f82251 Termination on corruption : ENABLED   Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast                      (k)     (k)    (k)     (k) length      blocks cont. heap  ----------------------------------------------------------------------------- 00670000 00000002 1020232 1012572 1020020    901   235    67    0      2   LFH 008c0000 00001002      60     16     60      4     2     1    0      0       00b20000 00001002      60     16     60      4     2     1    0      0       023d0000 00001002      60      4     60      0     1     1    0      0       025a0000 00041002      60      4     60      2     1     1    0      0       04d80000 00041002      60      4     60      2     1     1    0      0       ----------------------------------------------------------------------------- 0:000> !eeheap -gc Number of GC Heaps: 1 generation 0 starts at 0x3aeb6320 generation 1 starts at 0x3ae91000 generation 2 starts at 0x025b1000 ephemeral segment allocation context: none  segment     begin  allocated      size 025b0000  025b1000  02e70ee8  0x8bfee8(9174760) 3ae90000  3ae91000  3aeda364  0x49364(299876) Large object heap starts at 0x035b1000  segment     begin  allocated      size 035b0000  035b1000  036c2128  0x111128(1118504) Total Size:              Size: 0xa1a374 (10593140) bytes. ------------------------------ GC Heap Size:    Size: 0xa1a374 (10593140) bytes.  

从输出信息看,托管堆才区区 10M, 可以看到内存主要被 NT Heap 给吃掉了,因为没有开启 ust ,所以这块也搞不清楚是谁分配的。

如果仔细想一想,用 NT堆 的用户除了操作系统,还有 CLR,对,就是 CLR,所以看看与之相关的高频堆,低频堆,代码堆,或许有什么新发现,使用命令 !eeheap -loader

 0:000> !eeheap -loader Loader Heap: .... Module 57cf46f4: Size: 0x0 (0) bytes. Module 57cf4e8c: Size: 0x0 (0) bytes. Module 57cf5624: Size: 0x0 (0) bytes. Module 57cf5dbc: Size: 0x0 (0) bytes. Total size:      Size: 0x0 (0) bytes. -------------------------------------- Total LoaderHeap size:   Size: 0xff56000 (267739136) bytes. =======================================  

发现有海量的程序集,而且占用了 267M,肯定是有问题的,接下来抽几个 module 看下里面都有什么内容。

 0:000> !dumpmt -md 57cf61f8 EEClass:         57d08298 Module:          57cf5dbc Name:             mdToken:         02000002 File:            Unknown Module BaseSize:        0x44 ComponentSize:   0x0 Slots in VTable: 8 Number of IFaces in IFaceMap: 0 -------------------------------------- MethodDesc Table    Entry MethodDe    JIT Name 78c497b8 7884c838 PreJIT System.Object.ToString() 78c496a0 78988978 PreJIT System.Object.Equals(System.Object) 78c521f0 78988998 PreJIT System.Object.GetHashCode() 78c04f2c 789889a0 PreJIT System.Object.Finalize() 57d10c85 57cf61d4   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.InitCallbacks() 57d10c89 57cf61dc   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer..ctor() 57d10c7d 57cf61bc   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.Write3_FabrikamCustomer(System.Object) 57d10c81 57cf61c8   NONE Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterCustomer.Write2_Customer(System.String, System.String, ConsoleApp12.Customer, Boolean, Boolean)  

可以发现这里面都是 XmlSerialization 相关类,这说明内存泄漏和它有关,但还找不出是哪个代码泄漏的,头疼哈。。。

3. 到底是谁泄漏的?

为了快速解决,这时候就可以祭出 PerfView 2.0.6(最新版本会报错) , 用它来监控程序集的加载事件,一旦程序中出现了加载事件,在内部进行拦截并记录 调用栈,主要还是借助了 ETW。

在 PerfView 面板中点击 Provider Browser 按钮选中 Loader 事件,如下图:

PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏

然后加上记录栈的key,即 @StacksEnabled=true,合并后就是:

 Microsoft-Windows-DotNETRuntime:LoaderKeyword:Always:@StacksEnabled=true  

执行完之后,就会看到 Events 项,在弹框中搜索 AssemblyLoad 事件,然后在 Time MSec 列点击右键选择 Open Any Stacks 打开此次加载的 线程调用栈, 如下图所示:

PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏

如果看到调用栈显示的是 乱码 的话,可以使用 Lookup Symbols 加载下符号,然后就可以看到清晰的调用栈,截图如下:

PerfView专题 (第四篇):如何寻找 C# 中程序集泄漏

终于在 调用栈 中发现,那个 DynamicAssembly 就是 GetCustomer 方法创建的哈。。。 到此终于找到原因。