.Net 3.5 中的 XMLSerialization 是否仍然存在已知的内存泄漏？答案

【问题标题】：Are there still known memory leaks with XMLSerialization in .Net 3.5?.Net 3.5 中的 XMLSerialization 是否仍然存在已知的内存泄漏？
【发布时间】：2009-01-22 13:23:21
【问题描述】：

Tess Ferrandez 的这篇文章http://blogs.msdn.com/tess/archive/2006/02/15/532804.aspx 概述了为什么使用 XMLSerialization 会导致内存泄漏。

泄漏是对象在内存中作为程序集实例化的结果，而不是对象，因此不是垃圾收集器的目标。

文章最初写在1.0/1.1 CLR上，但是关于2.0 CLR的更新不清楚。

我在一个仍处于测试阶段的 Web 应用程序中广泛使用 XMLSerialization/Deserialization 来进行 UI/服务器交换。对象只是 DTO（只有属性的对象）。

提前谢谢你！

【问题讨论】：

标签： .net memory-leaks

【解决方案1】：

实际上导致泄漏的部分是 XML 引擎为序列化目的生成的程序集从未被收集。从 CLR 2.0SP1 (.Net 3.5) 开始，情况仍然如此。一旦一个程序集被加载到一个进程中，它就不会被删除，直到包含该程序集的 AppDomain 也被卸载。

如果您在文章底部注意到，她提到了一种让 XML 引擎重用程序集的方法，这样内存就不会失控。

【讨论】：

你确定 .NET 2.0 SP1 是指 .NET 3.5 吗？
@abatishchev - .NET 3.5 使用 CLR2.0 SP1...所以是的

【解决方案2】：

主要通过 .NET 2.0 DynamicMethod 解决。但是，如果不使用 [XmlRoot] 属性，仍然会出现故障模式。详情请查看this article。

【讨论】：

动态方法不能解决从 AppDomain 卸载程序集的问题。它只创建可收集的方法。
据我在文章中的理解，他们仍然说如果您使用任何“特殊”构造函数，您可能会出现内存泄漏。
我的链接坏了。
只使用archive.org 来处理死页。完成。

【解决方案3】：

我在 2.0 中遇到了同样的问题，所以我可以确认那里仍然存在内存泄漏，但我没有使用 3.5 的经验。只要你只使用构造函数 XmlSerializer(type) 和 XmlSerializer(type, defaultNameSpace) 你应该是安全的，因为 XmlSerializers 将被自动缓存。如果您使用任何其他构造函数，则必须创建自己的缓存。

【讨论】：

【解决方案4】：

谢谢。似乎关键是使用 XmlSerializer(type) 并允许内存中的实例保持缓存。看来，如果您为类名设置别名，则缓存不起作用并且泄漏随之而来..我将不得不测试和监视以确定我们是否无泄漏。 -达斯汀

【讨论】：