在 .NET Compact Framework (WinCE 5) 中寻找内存泄漏答案

【问题标题】：Hunting for Memory Leaks in .NET Compact Framework (WinCE 5)在 .NET Compact Framework (WinCE 5) 中寻找内存泄漏
【发布时间】：2011-05-11 03:02:24
【问题描述】：

我正在使用 Compact .NET Framework v3.5 下的 Windows CE 设备上的基于事务的系统。我们发现，随着越来越多的事务被执行，可用的内存越来越少。显然是某种内存泄漏。

每次交易后，我们会读取两次内存读数；一个来自操作系统（一个 PInvoke 调用），一个来自垃圾收集器。我们发现操作系统读取正在增加内存使用量，而来自 GC 的读取保持相对稳定（大约 1MB 差异 +-）。

该应用程序利用 Microsoft 同步服务将信息存储在几个本地数据库 (SQL Server Compact v3.5) 上，并将它们与远程服务器同步。

如果这是 Windows XP，我只需使用 WinDbg 连接到可执行文件，然后分析堆以查看我是否正在创建永远不会被 GC 处理的对象。但是，我什至不知道托管堆是否是问题所在。

所以这个问题分为两部分：

1) 在托管应用程序（DataAdapters、Streams 等）中以这种方式泄漏内存的可能罪魁祸首是什么？

2) 哪些调试工具/技术可以帮助我找到确切的问题？

我知道这没什么好做的，但在这个阶段，我没有比这更多的信息了。

谢谢！

【问题讨论】：

标签： .net debugging memory-leaks compact-framework

【解决方案1】：

有两种方法可以解决这个问题。首先是查看托管对象及其生命周期。您可以使用Remote Performance Monitor (RPM) 查看 GC 堆的快照并进行比较。

您可以使用CLR Profiler 检查调用树并查看这些对象的来源。

这两个工具通常可以让您找到托管代码问题。

现在，重要的是你说 GC 没有报告任何增长，这告诉我 GC 堆很好，在这种特定情况下，这些工具不太可能找到太多。尽管如此，我还是列出了这些工具，因为它们将来可能会帮助您（或其他阅读本文的人）。

在您的情况下，听起来您有本机泄漏。您没有说哪种类型的内存正在泄漏——物理的还是虚拟的——但几乎可以肯定的是，某些东西正在制造没有被释放的本机分配。 SQL Compact 是我根据您对您的架构所说的话做出的猜测，因为该引擎是在本机代码中实现的，并在其之上有一个托管层。

我还猜测根本原因是您有一些小的托管对象（可能是 SqlCeTransaction 或 SqlCeCommand），它们各自具有较小的托管占用空间，但正在为您进行一些本机分配，并且这些对象仍然存在.

托管工具应允许您定位大量或不断增加的这些项目，并定位阻止 GC 杀死它们的根。验证您正在使用的所有 SqlCe 对象上调用 Dispose 也是一件好事。

如果所有这些都找不到，您可以深入了解native tools 中的一些内容，但它们根本无法很好地处理托管代码，并且不太可能为您提供太多信息。

【讨论】：

发现了问题，感谢您按照您的建议专注于 SQL Compact。我们使用的强类型 TableAdapter 类在实例化时会创建一个 SqlCeConnection 对象。这些连接永远不会被我们关闭，也不会被自动生成的代码关闭。根据 MSDN：如果 SqlCeConnection 超出范围，则不会关闭。您必须通过调用 Close 或 Dispose 显式关闭连接。当我们在应用程序的整个生命周期内对这些适配器进行单一实例化时，问题就大大减少了。仍有一些泄漏，但可能是其他适配器
...我们还没有保护。
是的，这也是我们从不使用自动生成的强类型类的另一个原因。主要原因是它们消耗资源很慢。
还有其他简单的选择吗？我更喜欢自动生成代码的可靠性（更不用说节省腕管综合症），但这些错误是一场噩梦。您还有其他选择可以兼顾两者吗？

【解决方案2】：

听起来您可能在某处缺少 EndInvoke？或者不关闭你的连接？

可能不是问题，但我们只是在我的工作中遇到了类似的问题......在几天的正常运行时间后，几个丢失的 EndInvoke 调用完全锁定了我们的服务器......就像我们在哪里必须下去硬启动盒子。

【讨论】：