asp.net - LOH分析说，GC根对象(System.Object)是内存泄漏的根源

Question

我有一个HttpHandler，它经常被调用。它使用Entity Framework完成其任务。

通过此Web应用程序的w3p.exe(使用一个单独的应用程序池)，已用内存的增长缓慢。我使用了ANTS memory profiler，并且那里有很多可用内存(LOH)。 ANTS说这些是GC root对象。我检查了我的代码，有一些int和string不能导致LOH!

我跟踪了泄漏源，但不幸的是，泄漏源是System.Object类型，具有很多null属性。还有一个LinkedList，一些HashTable和一个WeakHashTable。

我如何找到这个对象并修复LOH？返回true的IsReusable的HttpHandler怎么办？

Answer 1

首先，您必须跟踪实际发生的情况。在这种情况下，我的第一个工具始终是WinDbg。

http://www.windbg.org/
http://en.wikipedia.org/wiki/WinDbg

要将其与托管/.NET代码一起使用，您需要使用SOS(Son of Strike)扩展名:

http://msdn.microsoft.com/en-us/library/bb190764.aspx

http://blogs.msdn.com/b/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx

因此，将WinDbg附加到w3wp.exe进程后，您要做的第一件事就是弄清楚堆中的实际内容:

!dumpheap -stat

这将为您提供一个格式化好的 View ，显示内存中所有当前“ Activity ”的对象，以及其中有多少个对象，它们占用了多少字节(按对象类型分组)。

现在，大对象堆(LOH)-通常，当对象被垃圾收集时，就会发生压缩，就像对硬盘驱动器进行碎片整理一样。这样可以快速有效地分配新对象。问题是，大型物体不容易压缩-一切都必须四处移动以适应它们。因此，占用超过85000字节的任何内容都被卡在一个称为“大对象堆”的特殊位置。这个堆没有被压缩，所以随着时间的流逝，就像硬盘驱动器一样，会发生碎片化，在堆中留下未使用的间隙，这导致运行时需要更多空间，等等。

因此，让我们问问windbg告诉我们LOH中的内容:

!dumpheap -stat -min 85000

这将向您显示大对象堆中的实际内容-其中一些对象可能会直接跳到您的身旁，例如List或MyClass []。

重要说明:如果您在大型对象堆中看到的东西是故意长期存在的(例如，像记录器的静态实例)，则可能并不是真正的问题。您确实想尽量减少其中的短暂/经常创建的对象的数量，以减少碎片。

因此，我建议您进行SOS探索备忘单:

http://windbg.info/doc/1-common-cmds.html

http://windbg.info/doc/2-windbg-a-z.html

有趣的命令:

!gcroot <address>   <- will show you what object is "rooting" another
!CLRStack           <- show current managed call stack
!dumpobj <address>  <- show information about object at address

但我一直以来最喜欢的是:

bp clr!SVR::gc_heap::allocate_large_object "!CLRStack; g;"

它在CLR在大对象堆上分配对象时使用的实际内部调用上设置一个断点，该对象在命中时将转出完整的堆栈跟踪，然后继续。