LOH分析说，GC根对象（System.Object）是内存泄漏的来源

首先，您必须跟踪实际发生的事情。在这种情况下，我的第一个工具始终是WinDbg。 http://www.windbg.org/ http://en.wikipedia.org/wiki/WinDbg 要将其与托管/.NET代码一起使用，您需要使用SOS（罢工之子）扩展名： 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

这将为您提供内存中所有当前“活动”对象的格式良好的视图，以及其中有多少个对象，它们占用了多少字节（按对象类型分组）。 现在，大对象堆（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在大对象堆上分配对象时在实际内部调用上设置一个断点，当该对象被命中时，将转出完整的堆栈跟踪，然后继续。