使用远程性能监视器帮助查找泄漏

Question

我试图在使用远程性能监视器的Compact Framework应用程序中发现内存泄漏的来源。我设法删除了一些与刷子和其他图形对象有关的小问题，但我仍然不清楚导致主要问题的原因。

在这一点上，似乎永远不会回到原始计数的唯一对象是System.String对象。我觉得这很奇怪，因为我会认为为了使这些对象不被收集，包含它们的对象将不得不保留，但是没有其他类型的对象似乎随着System.Strings。

我想知道哪些新的String对象是应用程序返回到其原始状态（即登录屏幕）后剩下的对象。问题是，最初，应用程序加载大约2200个字符串对象，然后在处理“X”之后，它增加了另外70个从未收集的东西。我不知道如何识别这70个新的物体，以便找出谁正在抓住他们并作出适当的更正。

有没有人有没有收集字符串的经验？有什么办法可以将在过程“X”中创建的新对象与应用程序最初需要的新对象分开，以便我可以知道哪些是泄漏？任何意见，将不胜感激。

感谢

**更新

好吧......有事情很奇怪的东西。我开始怀疑是否有泄漏。

假设我在作为应用程序的原始起点的登录屏幕上记录了快照。想象一下，此时在内存中有1000个字符串对象。现在，如果我登录并从菜单中选择一个选项，我将在加载新屏幕后拍摄快照。假设加载这个表单增加了50个对象的字符串数量。当我在登录屏幕上注销并再次拍摄快照时，仅收集了其中的25个对象，其余的将从此保留在内存中。

奇怪的是，如果我不断重复这个过程，不会再有字符串对象累积。而不是字符串数量增加50，在这一点上只会添加25个，并且一旦我回到登录屏幕就会收集到相同的25个字符串。我在想，如果这是一个实际的泄漏，那么每次打开该屏幕时，字符串数将永久增加25，但这只是第一次发生。

这发生在我打开的每个新屏幕上。起初，总体字符串计数有一个小的永久性增加，但是一旦我加载了特定的屏幕，一旦我回到登录屏幕，在执行过程中任何字符串计数的增加都会被收集。

所有这些让我相信，也许这些字符串是CLR内部工作的一部分或类似的东西。它可能是由运行时完成的某种缓存吗？也许它是存储我的字符串常量更快加载？像那样的东西？我希望这不是太混乱。

Answer 1

如果您使用CF 3.5，则使用the CLR Profiler而不是RPM。它会告诉你所有的物体和产生它们的根源。它可以让你回溯根树，找出它们的分配位置。

编辑

所以你说，你是不是真正得到奥姆斯或任何aberrent行为？听起来就像你试图在没有必要时进行优化。这些字符串可能是JITter创建的表单标题等，如果/收集对象时会收集。但是，如果你实际上没有看到内存问题，它们确实不是非常重要。