使用 .Net Memory Profiler 诊断 .NET 应用内存泄漏(方法与实践)
memory_profiler用法
memory_profiler用法memory_profiler 是一个 Python 的库，用于分析代码中的内存使用情况。
它可以帮助我们找出潜在的内存泄漏或者内存使用过多的问题，并提供了一个方便的接口来监视代码的内存使用量。
下面是memory_profiler 的使用方法和一些示例：1. 安装 memory_profiler：可以使用 pip 命令来安装 memory_profiler：```pip install memory-profiler```2.在代码中添加装饰器：```pythondef my_function(:#这里是我们要分析内存使用情况的代码pass```3.运行分析器：使用 `python -m memory_profiler my_script.py` 命令来运行我们的代码。
其中 `my_script.py` 代表我们要运行的 Python 脚本。
4.分析结果：运行分析器之后，它会输出代码在每个函数中的内存使用情况。
示例输出如下：```Filename: my_script.pyLine # Mem usage Increment Line Contents================================================4 def my_function(:542.062MiB0.000MiB#这里是我们要分析内存使用情况的代码```在上面的示例中，我们可以看到 `my_function` 函数在执行时使用了 42.062 MiB 的内存。
5.解读结果：除了输出每个函数的内存使用情况，输出还包括每行代码的增量内存使用情况。
通过对比增量，我们可以更准确地找出内存使用量较高的代码。
在分析结果中，我们还可以看到每个函数的内存使用情况是否有增加。
如果有增加，可能意味着存在内存泄漏的问题。
6.进阶用法：除了上述基本用法，memory_profiler 还提供了其他一些功能，例如：- 使用 `mprof` 命令行工具对代码进行内存使用量的时间序列分析；综上所述，memory_profiler 是一个强大的工具，可以帮助我们找出代码中的内存问题。
推荐5款超实用的.NET性能分析工具
推荐5款超实用的.NET性能分析工具作者把平时工作中使用到的非常不错的.Net分析工具进行总结，在此分享给大家。
希望它们能帮助到你！虽然.NET框架号称永远不会发生内存泄漏，原因是引入了内存回收机制。
但在实际应用中，往往我们分配了对象但没有释放指向该对象的引用，导致对象永远无法释放。
最常见的情况就是给对象添加了事件处理函数，但当不再使用该对象时却没有将该函数从对象的事件handler中减掉。
另外如果分配了非托管内存，而没有手工释放，GC同样无能为力。
所以当.NET应用发生内存泄漏后如何跟踪应用的内存使用情况，定位到程序设计中的缺陷显得非常重要。
下面想大家推荐5款非常实用的性能分析、内存优化工具。
觉得让你收获满满！1.JetBrains dotTraceJetBrains dotTrace是一款性能和内存分析工具，它可以帮助你优化应用程序性能指标，支持.NET 1.0版本到4.5，快速分析程序瓶颈，找出影响效率的代码。
官方网站上面有10天试用版，大家可以点击下载使用。
2.ANTS Performance ProfilerANTS性能分析器是一种用于分析.NET框架支持的用任何语言编写的应用程序的工具。
ANTS性能分析器能分析所有.NET应用程序，包括网络应用程序、Windows服务和COM+应用程序。
ANTS性能分析器能在几分钟内识别性能瓶颈，运行非常快速，且响应时，对程序的执行具有最低影响。
ANTS性能分析器可用作一种独立工具，也可用作Red Gate .NET Developer Bundle的一部分。
目前支持14天免费试用，大家可以去体验体验。
3.EQATEC Profiler另一个非常好的.NET分析器，它拥有多个版本，有免费版，标准版、专业版等。
不仅使用方便，而且优化速度也相当快。
4.Telerik Just TraceTelerik Just Trace是一款帮你轻松找出内存泄漏的分析工具，并且可以轻松搞定许多性能问题。
Android中常见的内存泄漏问题和解决方案
Android中常见的内存泄漏问题和解决方案Android是目前最流行的移动操作系统之一，但由于其开发过程中的一些特殊性，导致了一些常见的内存泄漏问题。
本文将针对这些问题进行深入的探讨，并提供相应的解决方案。
1. 概述内存泄漏是指在程序运行过程中，由于错误的内存管理导致无法释放已经不再使用的内存资源，从而造成内存消耗过大或者内存溢出的问题。
在Android开发中，内存泄漏是常见的问题之一，特别是在长时间运行的应用中，更容易引发内存泄漏。
2. 常见的内存泄漏问题2.1 匿名内部类造成的泄漏在Android开发中，经常使用匿名内部类来实现事件监听器等功能。
但如果在匿名内部类中持有外部类的引用，并且没有及时释放该引用，就会造成内存泄漏。
解决这个问题的方法是，使用弱引用（WeakReference）或者静态内部类来持有外部类的引用，从而避免内存泄漏。
2.2 非静态内部类的静态引用在Android开发中，非静态内部类持有外部类的引用是很常见的。
但如果这个非静态内部类的实例被长时间持有，并且这个非静态内部类持有了外部类的引用，那么就会造成内存泄漏。
解决这个问题的方法是，将非静态内部类声明为静态内部类，或者将内部类持有的引用设置为弱引用。
2.3 资源未正确释放在Android开发中，经常使用各种资源，如数据库连接、文件流等。
如果在使用完这些资源后没有正确释放，就会造成内存泄漏。
解决这个问题的方法是，在使用完资源后及时关闭或者释放这些资源。
2.4 单例模式导致的泄漏在Android开发中，经常使用单例模式来管理某些全局的对象。
但如果这些单例对象持有了外部对象的引用，并且这些单例对象的生命周期超过了外部对象的生命周期，就会造成内存泄漏。
解决这个问题的方法是，使用弱引用或者在适当的时候释放单例对象的引用。
3. 解决方案3.1 避免使用匿名内部类在Android开发中，尽量避免使用匿名内部类来实现事件监听器等功能。
可以考虑使用静态内部类或者弱引用来代替匿名内部类，从而避免内存泄漏的问题。
常见的内存泄漏以及解决方案
常见的内存泄漏以及解决⽅案⼀、什么是内存泄漏？ 系统进程不再⽤到的内存，没有及时的释放，就叫做内存泄漏。
⼆、JS引起内存泄漏的原因？1、意外的全局变量 由于js对没有进⾏申明的变量会默认是在全局变量上定义的，⽽系统的全局变量是 window，只有关闭窗⼝和刷新页⾯，全局变量才会被释放，如果在⼀个没有声明的变量上保存了⼤量的数据，这些数据就会保存在全局变量上，当这些数据没有及时的被回收，就会发⽣内存泄漏。
没有声明的变量function fn(){a='hello'}fn();使⽤this申明的变量function fn(){// 这⾥的this指向它的调⽤者，他的调⽤者是windowthis.a='hello';}fn() 解决⽅法: 避免使⽤没有声明的变量; 使⽤严格模式，在js⽂件头部或者是函数⾸⾏使⽤严格模式2、闭包引⽤的内存泄漏 由于闭包可以访问函数内部的变量，让这些变量⼀直保存在内存中，如果没有及时的清理掉这些变量，就会发⽣内存泄漏。
function fn(){var a='i am a';return function(){console.log(a);}} 解决⽅法：将事件处理程序定义在函数的外部// badfor(var k=0;k<10;k++){var t=function(a){console.log(a)}t(k)}// goodfunction t(a){console.log(a)}for(var k=0;k<10;k++){t(k)}t=null3、Dom元素的引⽤没有被释放 虽然在别的地⽅Dom别删除了，但是对象对这个Dom元素的引⽤并没有被删除var element={btn:document.getElementById('btn')}function doSomeThing(){element.btn.cilck()}function removeClick(){// 虽然移除了dom中的btn元素，但是对象中对btn的引⽤还是没有被删除document.body.removeChild(document.getElementById( 'btn' )) 解决⽅法：将element.btn=null4、被遗忘的定时器或者回调函数 定时器中有dom的引⽤，即使dom删除了，但是定时器还在，所以内存中还是会有这个dom。
电脑内存泄漏该如何诊断和修复
电脑内存泄漏该如何诊断和修复在我们日常使用电脑的过程中，可能会遇到各种各样的问题，其中内存泄漏就是一个比较常见但又让人头疼的情况。
内存泄漏指的是程序在运行过程中，不断地分配内存但没有及时释放不再使用的内存，导致可用内存逐渐减少，最终可能会使系统性能下降，甚至出现程序崩溃的情况。
那么，当我们遇到电脑内存泄漏时，该如何诊断和修复呢？下面就让我们一起来探讨一下。
一、内存泄漏的症状在诊断内存泄漏之前，我们首先需要了解一些内存泄漏可能导致的症状。
以下是一些常见的表现：1、系统运行速度逐渐变慢随着时间的推移，您可能会发现电脑的响应速度变得越来越慢，打开程序、文件或进行其他操作时都需要更长的时间。
2、频繁出现内存不足的错误提示当内存泄漏严重时，系统可能会弹出“内存不足”的警告，提示您关闭一些程序以释放内存。
3、程序崩溃或异常退出某些程序可能会突然崩溃，或者在运行过程中出现异常错误，无法正常工作。
4、系统重启或死机如果内存泄漏问题非常严重，可能会导致系统重启甚至死机，使您正在进行的工作丢失。
二、诊断内存泄漏的方法当我们怀疑电脑存在内存泄漏问题时，可以通过以下几种方法来进行诊断：1、任务管理器在 Windows 系统中，我们可以通过按下 Ctrl ＋ Shift ＋ Esc 组合键打开任务管理器。
在“性能”选项卡中，可以查看当前的内存使用情况。
如果发现内存使用率一直处于高位，并且在关闭一些程序后仍然没有下降，那么就有可能存在内存泄漏。
2、资源监视器Windows 系统还提供了资源监视器工具，可以更详细地查看内存的使用情况。
按下 Win ＋ R 键，输入“resmon”并回车即可打开。
在资源监视器中，可以查看每个进程的内存使用情况，包括提交大小、工作集、私有工作集等。
通过观察这些数据的变化，可以判断是否有进程存在内存泄漏。
3、性能监视器通过性能监视器（在 Windows 系统中可以在控制面板中找到），我们可以创建一个自定义的性能计数器来监测内存的使用情况。
使用AndroidStudio提供的AndroidProfiler工具和mat进行内存泄漏分析
使用AndroidStudio提供的AndroidProfiler工具和mat进行内存泄漏分析AndroidProfiler是Android Studio 提供的一个强大的性能分析工具，它可以帮助我们识别和解决应用中的内存泄漏问题。
同时，我们还可以使用MAT（Memory Analyzer Tool）来进一步分析内存泄漏的原因。
首先，我们需要运行我们的应用程序，并连接我们的设备或模拟器。
然后，我们可以打开Android Studio并选择“Android Profiler”选项卡。
在这个选项卡中，我们可以看到CPU、内存、网络和电池等资源的使用情况。
在内存部分，我们可以看到应用程序的内存使用情况和堆栈跟踪。
我们可以使用堆栈跟踪来分析哪些对象正在使用内存，以及它们是如何被创建和释放的。
当我们发现内存使用量异常高时，我们可以使用MAT工具来进一步分析内存泄漏的原因。
首先，我们需要导出堆转储文件（heap dump）。
在Android Studio中，我们可以通过运行应用程序并在内存部分的右上角点击“Dump Java Heap”按钮来导出堆转储文件。
导出文件后，我们可以使用MAT工具进行分析。
打开MAT工具后，我们可以选择导入我们刚刚导出的堆转储文件。
然后，MAT会分析堆转储文件，并提供一些有用的功能来分析内存泄漏。
在MAT工具中，我们可以使用“Histogram”功能来查看内存中的对象数量和大小。
这将帮助我们找到可能造成内存泄漏的对象。
另一个有用的功能是“Leak Suspects”。
MAT会自动分析堆转储文件，并提供一些潜在的内存泄漏嫌疑对象。
我们可以点击这些对象来查看详细信息，包括对象的引用链。
通过分析引用链，我们可以找到内存泄漏的根本原因。
通常，内存泄漏是由于对象仍然保留了对其他对象的引用，导致这些对象无法被垃圾回收。
一旦我们找到了内存泄漏的原因，我们可以采取相应的措施来解决问题。
这可能包括释放不必要的引用、使用弱引用或软引用来避免长时间持有对象等。
内存泄漏的检测定位和解决经验总结
内存泄漏的检测定位和解决经验总结内存泄漏是指在程序运行过程中，分配的内存一直没有被释放，导致内存的使用量越来越大，最终耗尽系统资源，造成程序崩溃。
内存泄漏是一种常见的程序缺陷，需要及时发现和解决。
一、检测内存泄漏的方法有以下几种：1. 静态代码检查：通过静态代码分析工具进行检查，工具可以扫描代码中的内存分配和释放情况，并发现潜在的内存泄漏问题。
常用的静态代码检查工具包括Coverity、PMD等。
2. 动态代码检查：通过运行时检查工具对程序进行监控，记录内存分配和释放的情况，检查是否有未释放的内存。
常用的动态代码检查工具包括Valgrind、Dr.Memory等。
3. 内存使用分析工具：通过监控程序的内存使用情况，包括内存的分配与释放，内存占用量等信息，来判断是否存在内存泄漏。
常用的内存使用分析工具有Google Performance Tools、Eclipse Memory Analyzer 等。
二、定位内存泄漏的方法有以下几种：1.添加日志：在程序中添加日志跟踪内存的分配与释放情况，当发现内存没有被释放时，通过日志定位问题的位置。
可以通过添加打印语句或者使用专门的日志工具来完成日志记录。
2. 使用内存调试工具：内存调试工具可以跟踪程序中的内存分配和释放情况，并将未被释放的内存标记出来。
通过分析工具提供的报告，可以定位内存泄漏的位置。
常用的内存调试工具有Valgrind、Dr.Memory等。
3. 内存堆栈分析：当程序出现内存泄漏时，通过分析内存堆栈可以得到导致内存泄漏的代码路径。
可以使用工具来进行内存堆栈分析，例如Eclipse Memory Analyzer。
三、解决内存泄漏的方法有以下几种：1. 显式释放内存：在程序中显式地调用释放内存的函数，确保内存被正确地释放。
例如，在使用动态内存分配函数malloc或new分配内存后，必须使用free或delete释放内存。
2. 自动垃圾回收：使用编程语言或框架提供的垃圾回收机制，自动释放不再使用的内存。
检测内存溢出的方法
检测内存溢出的方法
内存溢出是一种常见的程序错误，它通常发生在程序运行过程中，当程序试图分配超过其可用内存容量的对象时。
这种错误会导致程序崩溃或异常终止，严重影响程序的功能和稳定性。
为了避免这种错误的发生，我们需要及时检测和解决内存溢出问题。
以下是一些常用的检测内存溢出的方法：
1. 监控内存使用情况
通过监控程序的内存使用情况，及时发现内存泄漏或使用过度的情况。
可以使用系统工具或第三方工具来监控内存使用情况，例如Linux下的top、htop命令或者Java VisualVM等工具。
2. 执行代码分析
通过执行代码分析工具，可以检测出代码中存在的内存泄漏等问题。
常用的代码分析工具有Valgrind、Eclipse Memory Analyzer等。
3. 进行压力测试
通过模拟实际运行环境下的高负载情况，检测程序在压力下是否会发生内存溢出等错误。
可以使用JMeter等工具进行压力测试。
4. 使用断言
在程序中加入断言语句，判断内存分配是否成功，避免程序在分配内存失败时继续运行而导致崩溃。
总之，内存溢出是一个非常棘手的问题，需要我们及时发现和修复。
以上提到的方法只是其中一部分，更多的解决方法需要我们在实际开发中积累和总结。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用 .Net Memory Profiler 诊断 .NET 应用内存泄漏（方法与实践）文章分类:.net编程 关键字: memory leak, .net, .net memory profiler, 做过应用诊断与优化的朋友都知道内存泄漏和带来的危害，对这种情况的分析和定位一般会比较困难，尤其在 .NET/Java 应用中，隐式的堆内存管理以及托管对象间纷繁复杂的引用关系，使分析和定位问题更加复杂。
本文以我的了解，尽量说明了：1.一种对 .NET/Java 托管内存类应用的内存泄漏分析和诊断方法；2.使用 .Net Memory Profiler 工具对一个真实 应用中存在内存泄漏问题的分析、诊断实践过程作为示例。
本文包括以下问题、不足：1.本文以我的现有理解写成，尤其是“方法”相关的内容，每个人在不同情况下会有不同的方式；2.不是 .Net Memory Profiler 工具的全面讲解，实践中所涉及的功能仅是为了定位这里 应用中的问题。
可参见 .Net Memory Profiler 文档 。
.NET/Java 托管内存类应用的内存泄漏分析和诊断方法首先是些科普知识，理解的兄弟请自行快速跳过。
在托管内存管理中，“泄漏”意义不同与传统 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 中分配（移送）对象。
明白上面的基本道理，下面看看和托管对象实例内存泄漏的图例：上面图中表示的意思是使用一段时间后，堆中对象与 Root 对象的引用关系，其中颜色由浅到深表示了 Age 的因素。
如果此时，GC 线程执行，堆情况将如下所示：其中所有 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 工具实践首先要看下 .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.再说说这个 应用，前两天事业部的一个 应用出现了内存泄漏的情况。
现象是，在一个查询业务场景中，发现查询几次之后 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。
通过过两次比较可以看到如下内容：从中可以了解到：1.展现的所有内容是其于 3# snapshot 与 2# snapshot 两次快照的对比结果； Memory Profiler 提供了 Types 所有照到的对象类型，Show types可以指定显示类型的范围，包括所有、“新”对象（第二个 dump/snapshot 相对于第一个 dump/snapshot 里存在的新对象）等；Type details 每个类型的对象实例信息；Instance details 每个实例的详细信息；Callstacks/Methods 方法调用栈；Native memory 非托管内存信息；3.另外需要注意的是 Field Sets，包括 Standard、Dispose Info、HeapUtilization，用于过滤显示的 Types 类型结果。
比较有用，能够看到上面方法中提到的 Dispose 方法调用后仍然在在的对象类型有哪些，这可以缩小检查范围，下面会涉及到。
接下来就需要有针对性的逐一排查了，道先要考虑的是哪种类型的对象最有可能发生泄漏。
上面的方法中提供了优先级别。
我在这里是这样考虑的，因为对应用比较了解，我知道在有问题的业务页面中，有一个 static 类型的成员变量，它是 XmlDataSource 类型的对象，由于 static 所以实例不会被 GC，所以检查它所引用的有哪些对象实例就很有意义了。