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

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。它将向您显示所有对象以及产生它们的根。这将允许您返回根树以找出它们被分配的位置。

编辑

所以您是说您实际上并没有收到 OOM 或任何异常行为？听起来您正在尝试在不需要时进行优化。这些字符串可能是 JITter 正在创建的表单标题等内容，如果/当对象被收集时，它们会被收集。但是，如果您实际上没有看到内存问题，那么它们实际上并不是非常重要。