我正在尝试使用远程性能监视器在Compact Framework应用程序中找到内存泄漏的来源。我设法删除了一些与画笔和其他图形对象相关的次要内容，但我仍然不清楚导致主要问题的原因。
此时，似乎永远不会回到原始计数的唯一对象是System.String对象。我发现这很奇怪，因为我认为为了使这些对象保持未收集状态，包含它们的对象必须保持不变，但是没有其他类型的对象似乎随着System.Strings。
我正在尝试找出哪些新的String对象是应用程序返回其原始状态后保留的对象（即登录屏幕）。问题是，最初，应用程序加载了大约2200个字符串对象，然后在进程“X”之后它再增加70左右，从未收集到。我不知道如何识别这70个新物体，以便找出谁在抓住它们并进行适当的修正。
有没有人有没有收集字符串的经验？有没有办法将进程“X”中创建的新对象与应用程序最初需要的对象分开，以便我可以知道哪些是泄漏的？任何建议将不胜感激。
谢谢
**更新
好的......有一些非常奇怪的事情发生了。我开始怀疑是否存在泄漏。
假设我在登录屏幕上拍摄了一张内存快照，这是应用程序的原始起点。想象一下，此时内存中有1000个字符串对象。现在，如果我登录并从菜单中选择一个选项，我将在加载新屏幕后拍摄快照。假设加载此表单会增加50个对象的字符串数。当我在登录屏幕上注销并再次拍摄快照时，只收集了其中的25个对象，其余的将从那时开始留在内存中。
奇怪的是，如果我继续重复这个过程，就不会再积累更多的字符串对象。而不是字符串计数增加50，此时只会添加25，并且一旦我返回登录屏幕，将收集相同的25。我想如果这是一个实际的泄漏，那么每次打开那个屏幕时，字符串计数会永久增加25，但这只会在第一次发生。
在我打开的每个新屏幕上都会发生这种情况。首先，整个字符串数量会有一个小的永久性增加，但是一旦我加载了特定的屏幕，一旦我返回登录屏幕，将会收集执行过程中字符串计数的任何增加。
所有这些让我相信这些字符串可能是CLR内部工作的一部分或类似的东西。可能是运行时完成的某种缓存吗？也许它存储我的字符串常量以加快加载速度？那样的东西？我希望这不会太混乱。
答案 0 :(得分：0)
如果您使用的是CF 3.5，则使用the CLR Profiler而不是RPM。它将向您显示所有对象和产生它们的根。它将允许您返回根树以找出它们的分配位置。
修改
所以你说你实际上没有获得OOM或任何异常行为？听起来你正在尝试在没有必要时进行优化。这些字符串可能是JITter正在创建的表单标题等，如果/当对象被收集时会被收集。但是，如果你实际上没有看到记忆问题，那么它们真的不是非常重要。