.NET托管内存类应用的内存泄漏分析和诊断(转)
2024-04-10 14:39:04
在托管内存管理中，“泄漏”意义不同与传统 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 是什么，就不翻译了。我理解它实际就是个托管堆的 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。通过过两次比较可以看到如下内容：
点击查看大图
从中可以了解到：
1.的所有内容是其于 3# snapshot 与 2# snapshot 两次快照的对比结果；
2..NET Memory Profiler 提供了 Types 所有照到的对象类型，Show types 可以指定显示类型的范围，包括所有、“新”对象（第二个 dump/snapshot 相对于第一个 dump/snapshot 里存在的新对象）等；Type details 每个类型的对象实例信息；Instance details 每个实例的详细信息；Call stacks/Methods 方法调用栈；Native memory 非托管内存信息；
3.另外需要注意的是 Field Sets，包括 Standard、Dispose Info、Heap Utilization，用于过滤显示的 Types 类型结果。比较有用，能够看到上面方法中提到的 Dispose 方法调用后仍然在在的对象类型有哪些，这可以缩小检查范围，下面会涉及到。
接下来就需要有针对性的逐一排查了，道先要考虑的是哪种类型的对象最有可能发生泄漏。上面的方法中提供了优先级别。我在这里是这样考虑的，因为对应用比较了解，我知道在有问题的业务页面中，有一个 static 类型的成员变量，它是 XmlDataSource 类型的对象，由于 static 所以实例不会被 GC，所以检查它所引用的有哪些对象实例就很有意义了。查看该类型的详细信息可见：
点击查看大图
唯一的 XmlDataSource 类型实例是 #13, 483 号（全局实例编号）对象，通过详细信息可以看到如下被其引用的对象集：
点击查看大图
通过对引用它的对象一一检查后发现，#13, 483 号的 XmlDataSource 类型实例共引用了 6 个 XmlDataSourceView 对象（之所以是 6 个，是因为我做了 3 次 snapshot，每次 LoadRunner 测试脚本中都执行了 2 次查询操作），通过它们的 Age 可以看到都经过了多次 GC，但都没有释放掉。
点击查看大图
具体到 Root 对象集的引用路径也很简单，只有一条，它们都引用了#13, 483 号实例的事件。通过这样的分析，我们就能够找到由于与 static XmlDataSource 类型对象的引用关系，这造成了每次查询生成的 XmlDataSourceView类型对象都无法被 GC 回收，因此形成了内存泄漏情况。解决办法也很简单，可以通过将页面中 XmlDataSource 类型对象做为非 static 成员变量即可。
通过修复上面这个对象泄漏问题，我们每次业务可以节约接近 11M 的托管内存。但是通过之前的监控来看，每次业务所增加的内存量要比这大很多，而且通过修复上面的问题也不能完全解决内存持续上涨的情况。可以认定，该业务中还存在有内存泄漏的其它位置，需要继续分析、诊断。这次我通过 Dispose Info 着手，上面说过了，.NET 对象在经过程序调用 Dispose 方法后，就应该不再被使用并被 GC 所回收，如果在 snapshot 发现执行 Dispose 方法后 GC 多次仍未能回收的，就需要关注了。下面就是 Dispose 过后的对象类型：
点击查看大图
果然，可以看到在我们业务页面及其 Master 页面对象全部都是执行过 Dispose，但未 GC 掉。通过打开类型详细信息来查看可以发现，他们都被 SiteMap 所引用。
点击查看大图
我们都知道 SiteMap 及 XmpSiteMapProvider 等 ASP.NET 2.0 中站点地图的组件，它们都是由 .NET Framework 提供和管理的，我们是通过 site 文件配置出来的，那么造成这个原因是什么呢？通过调查了解到 SiteMap 对象的 SiteMapResolve 事件是static的，而 SiteMap 也是全局性质的，只要我们这些页面订阅了 SiteMapResolve 事件，就都会引用到 SiteMap 上去。有兴趣的朋友可参见MSDN SiteMap::SiteMapResolve Event的SiteMapResolve causing memory leaks 小节。而且，从对象树的内存使用量上看也比较合理了，每个页面由于包括了大量的控件及其状态数据，因此都很大，每个页面对象有 46M 多。
.NET托管内存类应用的内存泄漏分析和诊断(转)相关推荐
- .NET托管内存类应用的内存泄漏分析和诊断
在托管内存管理中,"泄漏"意义不同与传统 Native 应用中的忘记显式释放(delete/delete[] 等)不同,当然对于非托管资源之类(如句柄等)还是需要在 Finaliz ...
- 记一次 .NET 某桌面奇侠游戏 非托管内存泄漏分析
更多高质量干货:参见我的 GitHub: dotnetfly 一:背景 1. 讲故事 说实话,这篇dump我本来是不准备上一篇文章来解读的,但它有两点深深的感动了我. 无数次的听说用 Unity 可做 ...
- 记一次 .NET 某外贸Web站 内存泄漏分析
一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了 ...
- android释放acitity内存,Android 内存泄漏分析与解决方法
在分析Android内存泄漏之前,先了解一下JAVA的一些知识 1. JAVA中的对象的创建 使用new指令生成对象时,堆内存将会为此开辟一份空间存放该对象 垃圾回收器回收非存活的对象,并释放对应的内 ...
- new arraylist内存_Java内存泄漏分析工具Memory Analyzer Tool
阅读文本大概需要3分钟. 一个大型的Java项目也许从开发到测试结束并可能不能未发现一些重大的问题,但是在生产环境中还是会出现一些非常棘手的问题,如内存泄漏直接导致服务宕机,遇到这样的问题对于一个经验 ...
- 内存泄漏分析_调查内存泄漏第2部分–分析问题
内存泄漏分析 这个小型系列的第一个博客介绍了如何创建一个非常泄漏的示例应用程序,以便我们可以研究解决服务器应用程序上基于堆的问题的技术. 它展示了Producer-Consumer模式的一个大问题,即 ...
- 4大JVM性能分析工具详解，及内存泄漏分析方案
谈到性能优化分析一般会涉及到: Java代码层面的,典型的循环嵌套等 还会涉及到Java JVM:内存泄漏溢出等 MySQL数据库优化:分库分表.慢查询.长事务的优化等 阿里P8架构师谈:MySQL慢 ...
- java9 堆外内存_java堆外内存泄漏排查
当考虑Java中的内存泄漏时,我们通常会考虑Java堆泄漏,即在堆中分配的对象没有被垃圾收集.这是我在处理一台服务器内存泄漏时的想法,但我即将经历的远超出我的想象. 症状:运行Vertx应用程序(没有 ...
- Android内存泄漏分析及调试
2019独角兽企业重金招聘Python工程师标准>>> Android内存泄漏分析及调试 分类: Android2013-10-25 11:31 5290人阅读 评论(5) 收藏 举 ...
最新文章
- AI科普微视频丨人类的智能是如何产生的？
- 微服务配置中心是干啥的_微服务入门到精通-分布式配置中心（续）
- recv函数返回值说明
- Angular 服务器端渲染的学习笔记(一)
- BZOJ 2763: [JLOI2011]飞行路线 spfa dp
- 驱动对象-设备对象-设备栈
- Java设计模式01：设计模式的 分类 和 设计原则
- SolidWorks、inventor、UG...我该学哪个？主流三维机械设计软件对比
- python中match的六种用法_python re.match()用法相关示例
- CSDN公式插入——关于对数
- 【雅思大作文考官范文】——第十六篇：climate change essay
- 赵鑫：强化学习在京东广告序列推荐中的应用
- 技术之道、思维的力量和人生观
- 微软、IBM对垒大数据
- celery基础知识
- JS 轮播图 图片切换（定时器）
- 服务器微信了早上好,每天问候早上好的微信话语
- iOS_Tagged Pointer是什么，结构
- Gitlab配置Gitlab-Runner实现简单的CI/CD
- 如何提交网站地图，让谷歌、雅虎、百度统统收录