调试紧凑框架 2.0 中的内存泄漏答案

【问题标题】：Debugging memory leak in compact framework 2.0调试紧凑框架 2.0 中的内存泄漏
【发布时间】：2016-08-24 07:19:43
【问题描述】：

我正在使用 Windows 移动应用程序，运行紧凑框架 2 和 vb.net 代码。由于需要在每个确定的时间段同步应用程序，我使用 system.threading.timer 为每个同步过程设置预定义的计时器。

问题是，我的内存正在快速构建，迅速达到 24 MB，并且由于 OutOfMemoryException 而导致应用崩溃。

我知道紧凑框架的 GC 充其量并不好，只有 2MB 的 gc 堆，我每次同步使用 4 MB，而 gc 只清理 2MB，因为它的功能。

我尝试使用在紧凑框架 2.0 中构建的性能监视器工具，但它只为我提供了“仍然存在”的对象，并且没有清理或处置，而对每个部分发生的事情没有真正的概念应用程序。

紧凑型框架 2.0 中是否有任何有效的监控内存泄漏的方法？一个将指导我通过哪种方法导致问题或代码的哪一部分有问题？

或者以另一种方式，任何有用的方法来管理我的内存，比方说，更有效的方式，因为我只有 32MB 的可用内存空间，这是一个非常狭窄的问题。

【问题讨论】：

从我的角度来看，内存泄漏是指您分配一个对象并且在使用后没有释放（Dispose 并设置为 Null）它。我会在每个可疑函数之前和之后转储内存状态。之后进入不释放内存的函数并查找未释放的对象。请记住，只要进程中存在对该对象的引用，该对象就不会自动释放。
查看Compact Framework Power Toys 中可用的 NETCF CLR Profiler，它将显示每个对象的创建数量以及创建对象的方法。

【解决方案1】：

我怀疑这个问题与实际的内存泄漏有关。

连接您的设备并启动调试会话，并在 Visual Studio 的线程下拉列表中监控您的堆栈跟踪和线程数。我怀疑您在没有处理旧线程的情况下启动了太多线程，或者您对函数或子例程的循环调用使堆栈跟踪变得太大 - 您往往会在小型设备上发现内存不足堆栈溢出。

【讨论】：

【解决方案2】：

我们最终使用了为应用程序创建的内部数据库，我们得出的结论是，在这种情况下，纯粹处理 XML 文档并不聪明，因为我们有超过 300 个客户端来处理 XML 文件。我们最终不得不解析一个包含 19,000 行的 XML 文件，考虑到我们使用的平台，这太荒谬了，它只给了我们 24MB 的空间来使用。

我们创建了一个内部数据库来处理内部应用程序业务和 DAL 逻辑。

这样我们就不必处理巨大的 XML 文件，因此可以解决我们遇到的性能问题。

【讨论】：