.NET内存泄漏分析Windbg项目实例

一：背景

讲故事

上个月有位朋友找到我，说他的程序出现了内存泄漏，不知道如何进一步分析，截图如下：

什么大对象可挖。

0:000> !dumpheailder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

00007ffdea9ca260 5362921 2359685240 xxx.Bundle

从输出看，内存主要被 xxx.Bundle 和 AsyncTaskMethodBuilder 两大类对象给吃掉了，数量都高达 536w，这里有一个非常有意思的地方，如果你了解异步，我相信你一看就能看出 AsyncTaskMethodBuilder + VoidTaskResult 是干嘛的，按照经验，这位朋友应该误入了 异步无限递归 ，那怎么去挖呢？ 接着往下看。

3. 寻找问题代码

看到上面的 xxx.BundleBiz+<DistributionBundle>d__20 了吗？ 这个正是异步操作所涉及到的类和方法，接下来用 ILSpy 反射出 BundleBiz 下的匿名类 <DistributionBundle>d__20 , 如下图所示：

虽然找到了源码，但代码是 ILSpy 反编译出来的异步状态机，接下来的一个问题是，如何根据状态机代码反向寻找到 await ，async 代码呢？ 在 ILSpy 中有一个 used by 功能，在这里可以用起来了。

双击 used by 就能看到真正的调用代码,简化后如下：

public async Task DistributionBundle(List<Bundle> list, List<xxx> bwdList, xxx item, List<xxx> sumDetails, List<xxx> details, BundleParameter bundleParameter, IEnumerable<dynamic> labels){int num = 0;foreach (xxx detail in sumDetails){IEnumerable<xxx> woDetails = details.Where((xxx w) => w.Size == detail.Size && w.Color == detail.Color);foreach (xxx item2 in woDetails){            xxx}woDetails = woDetails.OrderBy((xxx s) => s.Seq).ToList();num++;        xxxBundle bundle = new Bundle();Bundle bundle2 = bundle;bundle2.BundleId = await _repo.CreateBundleId();foreach (xxx item3 in woDetails){item3.TaskQty = item3.WoQty + Math.Ceiling(item3.WoQty * item3.OverCutRate);decimal value = default(decimal);}await DistributionBundle(list, bwdList, item, sumDetails, details, bundleParameter, labels);}}

仔细看上面这段代码, 我去， await DistributionBundle(list, bwdList, item, sumDetails, details, bundleParameter, labels); 又调用了自身，看样子是某种条件下陷入了一个死递归。。。

有些朋友可能要问，除了经验之外，能从 dump 中分析出来吗？当然可以，从 500w+ 中抽一个看看它的 !gcroot 即可。

0:000> !DumpHeap /d -mt 00007ffdeb210098

Address MT Size

000001a297913a68 00007ffdeb210098 264

000001a297913b70 00007ffdeb210098 264

0:000> !gcroot 000001a29791ElLMqjLxPN3a68

Thread 5ac:

000000470B1EE4E0 00007FFE45103552 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2922]

rbp+10: 000000470b1ee550

-> 000001A297A25D88 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions+<RunAsync>d__4, Microsoft.Extensions.Hosting.Abstractions]]

-> 000001A29796D8C0 Microsoft.Extensions.Hosting.Internal.Host

...

-> 000001A298213248 System.Data.SqlClient.TdsParserStateObjectNative

-> 000001A32E6AB700 System.Threading.Tasks.TaskFactory`1+<>c__DisplayClass38_0`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient],[System.Data.CommandBehavior, System.Data.Common]]

-> 000001A32E6AB728 System.Threading.Tasks.Task`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]]

-> 000001A32E6ABB18 System.Threading.Tasks.StandardTaskContinuation

-> 000001A32E6ABA80 System.Threading.Tasks.ContinuationTaskFromResultTask`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]]

-> 000001A32E6AB6C0 System.Action`1[[System.Threading.Tasks.Task`1[[System.Data.SqlClient.SqlDataReader, System.Data.SqlClient]], System.Private.CoreLib]]

-> 000001A32E6AB428 System.Data.SqlClient.SqlCommand+<>c__DisplayClass130_0

...

-> 000001A32E6ABC08 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.String, System.Private.CoreLib],[Dapper.SqlMapper+<QueryRowAsync>d__34`1[[System.String, System.Private.CoreLib]], Dapper]]

-> 000001A32E6ABD20 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.String, System.Private.CoreLib],[xxx.DALs.xxx.BundleRepo+<CreateBundleId>d__12, xxx]]

-> 000001A32E6ABD98 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A32E6A6BD8 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A433250520 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A32E69E0F8 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A433247D28 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A433246330 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A32E69A568 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

-> 000001A433245408 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[xxx.BundleBiz+<DistributionBundle>d__20, xxx]]

...

从调用栈来看，代码貌似是从数据库读取记录的过程中陷入死循环的。

4. 为什么没有出现栈溢出

一看到无限循环，我相信很多朋友肯定要问，为啥没出现堆栈溢出，毕竟默认的线程栈空间仅仅 1M 而已，从 !gcroot 上看，这些引用都是挂在 5ac 线程上，也就是下面输出的 主线程 ,而且主线程栈也非常干净。

0:000> !t

ThreadCount: 30

UnstartedThread: 0

BackgroundThread: 24

PendingThread: 0

DeadThread: 5

Hosted Runtime: no

Lock

DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception

0 1 5ac 000001A29752CDF0 202a020 Preemptive 0000000000000000:0000000000000000 000001a29754c570 0 MTA

4 2 1e64 000001A29752A490 2b220 Preemptive 0000000000000000:0000000000000000 000001a29754c570 0 MTA (Finalizer)

...

0:000> !clrstack

OS Thread Id: 0x5ac (0)

Child SP IP Call Site

000000470B1EE1D0 00007ffe5eb30544 [GCFrame: 000000470b1ee1d0]

000000470B1EE318 00007ffe5eb30544 [HelperMethodFrame_1OBJ: 000000470b1ee318] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)

000000470B1EE440 00007ffe45103c25 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)

000000470B1EE4E0 00007ffe45103552 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cElLMqjLxPNs @ 2922]

000000470B1EE550 00007ffe451032cf System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2861]

000000470B1EE5D0 00007ffe45121b04 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 143]

000000470B1EE600 00007ffe4510482d System.Runtime.CompilerServices.TaskAwaiter.GetResult() [/_/src/System.Private.CoreLib/shared/System/Runtime/CompilerServices/TaskAwaiter.cs @ 106]

000000470B1EE630 00007ffe4de36595 Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(Microsoft.Extensions.Hosting.IHost) [/_/src/Hosting/Abstractions/src/HostingAbstractionsHostExtensions.cs @ 49]

000000470B1EE660 00007ffde80f3b4b xxx.Program.Main(System.String[])

000000470B1EE8B8 00007ffe47c06c93 [GCFrame: 000000470b1ee8b8]

000000470B1EEE50 00007ffe47c06c93 [GCFrame: 000000470b1eee50]

如果你稍微了解一点异步的玩法，你应该知道这其中有一个 IO完成端口 的概念，它可以实现 句柄 和 ThreadPool 的绑定，无限递归只不过是进了 IO完成端口 的待回调队列中而已，理论上和栈空间没什么关系，也就不会出现栈溢出了。

三：总结

本次内存泄漏的事故主要还是因为程序员的大意，也许是长期的 996 给弄恍惚了，有了这些信息，修正起来相信会非常简单。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。