使用 .Net Memory Profiler 诊断 .NET 应用内存泄漏（方法与实践） 文章分类:.net编程 关键字: memory leak, .net, .net memory profiler, asp.net 做过应用诊断与优化的朋友都知道内存泄漏和带来的危害，对这种情况的分析和定位一般会比较困难，尤其在 .NET/Java 应用中，隐式的堆内存管理以及托管对象间纷繁复杂的引用关系，使分析和定位问题更加复杂。本文以我的了解，尽量说明了： 1. 一种对 .NET/Java 托管内存类应用的内存泄漏分析和诊断方法； 2. 使用 .Net Memory Profiler 工具对一个真实 ASP.NET 应用中存在内存泄漏问题的分析、诊断实践过程作为示例。 本文包括以下问题、不足： 1. 本文以我的现有理解写成，尤其是“方法”相关的内容，每个人在不同情况下会有不同的方式； 2. 不是 .Net Memory Profiler 工具的全面讲解，实践中所涉及的功能仅是为了定位这里 ASP.NET 应用中的问题。可参见 .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 是...
