一篇文章教你如何排查.NET内存泄漏一篇文章教你如何排查.NET内存

前言
检查托管内存使用
生成dump文件
分析 core dump
总结

【一篇文章教你如何排查.NET内存泄漏】
前言内存泄漏通常表示：一个应用程序的某些对象在完成它的的生命周期后，由于它被其他对象意外引用，导致后续gc无法对它进行回收，长此以往就会导致程序性能的下降以及潜在的 OutOfMemoryException。
这篇我们通过一个内存泄漏工具对 .NET Core 程序进行内存泄漏分析，如果程序是跑在windows上，那直接可以使用 Visual Studio 进行诊断。

检查托管内存使用
在开始分析内存泄漏之前，你一定要有证据证明真的存在内存泄漏，这里可以用 dotnet-counters 来看下应用程序的各个指标来进行验证。
将程序跑起来

dotnet run

找出程序的 pid，

dotnet-counters ps4807 DiagnosticScena /home/user/git/samples/core/diagnostics/DiagnosticScenarios/bin/Debug/netcoreapp3.0/DiagnosticScenarios

使用 monitor 启动监视器，这里的 --refresh-interval 表示刷新间隔

dotnet-counters monitor --refresh-interval 1 -p 4807Press p to pause, r to resume, q to quit.Status: Running[System.Runtime]# of Assemblies Loaded118% Time in GC (since last GC)0Allocation Rate (Bytes / sec)37,896CPU Usage (%)0Exceptions / sec0GC Heap Size (MB)4Gen 0 GC / sec0Gen 0 Size (B)0Gen 1 GC / sec0Gen 1 Size (B)0Gen 2 GC / sec0Gen 2 Size (B)0LOH Size (B)0Monitor Lock Contention Count / sec0Number of Active Timers1ThreadPool Completed Work Items / sec10ThreadPool Queue Length0ThreadPool Threads Count1Working Set (MB)83

重点看一下 GC Heap Size (MB) 指标，可以看到程序启动后当前GC堆内存为 4M，打开链接：https://localhost:5001/api/diagscenario/memleak/20000后再看看GC堆内存,可以看到一下子就到 30M 了，如下所示：

GC Heap Size (MB)30

通过对比内存的使用，这下子可以拍胸脯的说，确认内存内存泄漏。

生成dump文件
要想分析程序的内存泄漏，首先要有访问GC堆的权限，这样就可以分析heap内存以及对象之间的关系，然后就可以大胆猜想为啥内存没有得到释放？要想生成 .NET Core 程序的dump文件，可以借助 dotnet-dump 工具。

dotnet-dump collect -p 4807Writing minidump with heap to ./core_20190430_185145Complete

分析 core dump
接下来可以使用 dotnet-dump analyze 对已生成的dump文件进行分析。

dotnet-dump analyze core_20190430_185145

这里的 core_20190430_185145 就是你想要分析的dump名，值得一提的是：如果你遇到了 libdl.so cannot be found 错误，建议以安装一下libc6-dev package 包。
首先我们通过 sos 命令查看托管堆上的所有对象统计清单。

> dumpheap -statStatistics:MTCountTotalSize Class Name...00007f6c1eeefba857659904 System.Reflection.RuntimeMethodInfo00007f6c1dc021c8174995696 System.SByte[]00000000008c9db03847116080Free00007f6c1e784a18175128640 System.Char[]00007f6c1dbf5510217133504 System.Object[]00007f6c1dc014c0467416464 System.Byte[]00007f6c2162503864063376 testwebapi.Controllers.Customer[]00007f6c20a674982000004800000 testwebapi.Controllers.Customer00007f6c1dc00f9020677019494060 System.StringTotal 428516 objects

从输出看，大头都是些 String 和 Customer 对象,然后可以通过 mt 参数来获取该方法表下所有的实例对象。

> dumpheap -mt 00007faddaa50f90AddressMTSize...00007f6ad09421f8 00007faddaa50f9094...00007f6ad0965b20 00007f6c1dc00f908000007f6ad0965c10 00007f6c1dc00f908000007f6ad0965d00 00007f6c1dc00f908000007f6ad0965df0 00007f6c1dc00f908000007f6ad0965ee0 00007f6c1dc00f9080Statistics:MTCountTotalSize Class Name00007f6c1dc00f9020677019494060 System.StringTotal 206770 objects

接下来可以用 !gcroot 查看某一个string到底被谁持有着？

> gcroot -all 00007f6ad09421f8Thread 3f68:00007F6795BB58A0 00007F6C1D7D0745 System.Diagnostics.Tracing.CounterGroup.PollForValues() [/_/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/CounterGroup.cs @ 260]rbx:(interior)->00007F6BDFFFF038 System.Object[]->00007F69D0033570 testwebapi.Controllers.Processor->00007F69D0033588 testwebapi.Controllers.CustomerCache->00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]->00007F6C000148A0 testwebapi.Controllers.Customer[]->00007F6AD0942258 testwebapi.Controllers.Customer->00007F6AD09421F8 System.StringHandleTable:00007F6C98BB15F8 (pinned handle)-> 00007F6BDFFFF038 System.Object[]-> 00007F69D0033570 testwebapi.Controllers.Processor-> 00007F69D0033588 testwebapi.Controllers.CustomerCache-> 00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]-> 00007F6C000148A0 testwebapi.Controllers.Customer[]-> 00007F6AD0942258 testwebapi.Controllers.Customer-> 00007F6AD09421F8 System.StringFound 2 roots.

从string的引用链看，它是被 CustomerCache 所持有，然后就可以到代码中寻找问题啦。
原文链接：https://docs.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak

总结到此这篇关于教你如何排查 .NET 内存泄漏的文章就介绍到这了,更多相关排查 .NET 内存泄漏内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！