在托管内存管理中，“泄漏”意义不同与传统 Native 应用中的忘记显式释放（delete/delete[] 等）不同，当然对于非托管资源之类（如句柄等）还是需要在 Finalize （析构方法等同于 Finalize）方法中显式释放的，在托管内存管理中“泄漏”对象实例指的是，由于与 Root 对象集中的对象存在本应断开的引用关系，而让 GC 线程认为该对象还被使用，因而不能被释放，尽管其不再会被使用。决大部分情况下，由于应用（程序员）认为该对象不会存在了，而在再次使用时，又在托管堆中再次创建了该对象实例，可以想象这样的后果很严重，随着创建次数增加堆内存会爆满。（托管堆中 G3 区爆满，G2 区无法腾出空间）。
GC 判断一个对象是否可以被释放是通过从被称为 Root 对象集中的根对象开始（如 Main 函数的 args 形参、static 变量及其对象成员等），遍历出所有被其引用的对象和子对象。GC 执行时通过标记这些引用中的对象，清除未标记上的对象来完成内存释放（标记、清理算法），当然清除也可能分步（如移送 Finalize 队列等）。由于标记、清理算法的中断时间等性能考虑，托管堆会分区（代），当前 CLR 是 3 代 – G1、G2、G3。伴随 Age（GC 一次 Age 加 1）增加，对象会逐渐从 G1 移送到 G3 代中（复制、整理算法），即 G1 是新生代，都是些短期对象，G3 是老年对象的永久居留地。需要说明的是，实际上在当前版本的 .NET CLR 中有 2 个托管堆（SOH 和 LOH），其中一个叫大对象托管堆（LOH），专门用来存放大于 84, 999 Bytes 的对象。程序只能在 SOH G1 和 LOH 中分配对象空间，只有 CLR GC 线程可以在 SOH 的 G2、G3 中分配（移送）对象。
明白上面的基本道理，下面看看和托管对象实例内存泄漏的图例：
.NET托管内存类应用的内存泄漏分析和诊断（图一）  
上面图中表示的意思是使用一段时间后，堆中对象与 Root 对象的引用关系，其中颜色由浅到深表示了 Age 的因素。如果此时，GC 线程执行，堆情况将如下所示：
.NET托管内存类应用的内存泄漏分析和诊断（图二） 
其中所有 Unreachable 的对象实例都将被 GC 所释放，这样托管堆内存会被正确回收。但需要说明的是，如果在 Reachable 的区域中（这部分 GC 是不会释放的），有一些被引用的对象在以后不会再使用，而且应用（程序员）在下次使用时还会创建新的对象时“泄漏”就发生了。当涉及对此类对象创建操作的业务被用户反复执行后，CLR 的 G3 代托管堆段会逐渐增长，服务的死期也就不远了。
有了以上的知识，可以说对内存泄漏的结构化诊断、定位方法如下：
1.监控托管堆使用量（查看 进程的内存占用量也可以），找到内存只长不降的业务，这些代码有内存泄漏的危险。这个过程我一般会使用 LoadRunner 脚本来做，毕竟小尺寸对象的泄漏需要较长的时间才能发生，靠手工操作不靠谱。这个一般不需要并发；
2.重新启动应用，让托管堆清理无关对象；
3.执行一次第1步发现的存在内存泄漏缺陷的业务；
4.使用工具将托管堆导出（dump）来，或对托管堆做一次快照（snapshot）。在 dump/ snapshot 前要做一次全面 GC（full GC），尽量把可对象释放干净，排除干扰。此时泄漏的对象已经不能 GC 掉了，会保存在托管堆中，都会被 dump/shot 出来；
5重复步骤 3。这会再次创建上次执行时（步骤 3）泄漏的对象；
6步骤 4。此时，泄漏的对象是作为本次 dump/shot 的新对象存在的，相对于步骤 4 中泄漏的同类对象而言；
7对比步骤 4 和 6 两次 dump/snapshot 结果，下面就需要在茫茫对象中找出泄漏的对象/对象类型来了。实际上这个过程是相对比较困难的，需要了解应用设计，相关背景知识，了然的越详细，定位越快，结果越准、完整。做两次 dump/snapshot 的目的在于，泄漏对象将属于“新”创建对象集范围，这将有效缩小需检查的对象范围。需要说明的是，这里的“新”指的是第二个 dump/snapshot 相对于第一个 dump/snapshot 里存在的新对象；
8前步骤的对象范围还是比较大，接下来可以从对象类型角度排个检查的优先级顺序：
◆检查应用命名空间中类型的对象；
◆检查框架所提供的类型的对象；检查已经执行过手动关闭/释放方法的对象。如 .NET 中的 IDisposable 接口的 Dispose 方法。因为一旦调用了这种方法，对象本应该被 GC 所释放的，它是不应该再存在的。对于此类对象，存在的原因有可能：
A．被短生命周期的对象所引用，如局部变量（包括形参变量）等，造成无法 GC。但在，在再次执行 dump/snapshot 时，它应该已经 GC 释放掉。
B．应用中设计了“池”，对象虽然被关闭，但它仍然会在池中存放，供下次使用时再打开。一般这种情况比较少见，尤其在 .NET 中，放入池中的对象很少会调用其 Dispose 方法。这方面 Java 也类似。
实际上面所说的结构化方法只是表达个意思，真实的过程会是一个逐步定位、迭代的过程，在理解其中意义的前提下，灵活使用。通过上面的一系列分析、诊断方法来定位到泄漏的对象后，就查找是它们是被哪些对象所引用，即 Root Path 中都有哪些对象，通过修改代码来切断不应存在的引用，就可以使泄漏对象进行正常的 Unreachable 状态，GC 线程也就会正确处理它们了。实际上，重点还是在分析、诊断、定位，修复方法还是很容易找到的。
首先要看下 .NET Memory Profiler 是什么，就不翻译了。我理解它实际就是个托管堆的 snapshot 工具，可以标记出非托管资源。显示实时堆使用图形的功能实在没大用。
.NET Memory Profiler is a tool for the .NET Common Language Runtime that allows the user to retrieve information about all instance allocations performed on the garbage collected heap (GC heap) and all instances that reside on the GC heap. The retrieved information is presented in real time, both numerically and graphically.
再说说这个 ASP.NET 应用，前两天事业部的一个 ASP.NET 应用出现了内存泄漏的情况。现象是，在一个查询业务场景中，发现查询几次之后 IIS 的 w3p 工作 进程会增长几兆、十几兆、几十兆不等的内存（这和查询结果大小成正比），而且通过 perfmon 监控可以看到 w3p 的 CLR 及时执行了 GC，但托管堆使用量始终只增不减，直到服务宕掉（在 LoadRunner 测试时还有 w3p crash 的情况）。
这里就不详细说明使用 .NET Memory Profiler 工具使用细节了，相信能看到这里的朋友，对这个工具的基本使用肯定不会成问题的。下面直接说重点。
按照上面提供的方法（内存泄漏的结构化诊断、定位方法），首先我们已经找到了在在问题的业务，也能够重现它。接下来将服务重启，让 w3p 的托管堆初始干净，排除无关对象。然后执行一次有问题的业务，这里我使用的 LoadRunner Vuser 回放测试脚本。接下来就要请 .NET Memory Profiler 出马，对 w3p 进程托管堆做次 snapshot。每个快照之前 .NET Memory Profiler 会自动做一次 Full GC。再来做一次执行查询业务，然后再做snapshot。通过过两次比较可以看到如下内容：
.NET托管内存类应用的内存泄漏分析和诊断（图三）
点击查看大图