如何查看.NET内部字符串

在CLR 2.0中，是否有任何方法可以查看所有已插入的字符串？我查看了CLR Profiler API，没有看到任何API调用在字符串被插入时进行监视。另外，插入字符串的范围是什么？当卸载应用程序域时，是否会收集托管字符串，或者这些字符串是否跨应用程序域

在.NET2.0中默认情况下，字符串确实会被插入，但是哪些字符串以及何时被插入可能相当复杂。以下文章可能会对这一概念有所启发：

---

另外，关于您的API调用……请确保您正在使用优化的构建进行测试。默认情况下，调试生成可能不会启用字符串插入，这可能就是您没有看到它发生的原因

谢谢澄清。不知何故，我似乎总是设法在这件事上有所进展-|谢谢你的链接，我在谷歌上找到了这个。我正在研究一个手动的ETL过程，该过程需要进行大量的字符串处理，我们看到了大量的内存消耗。我推测我正在使用的API是在幕后进行字符串实习的，我正在寻找类似perfmon计数器或VS调试窗口的东西，在那里我可以看到实习“池”中的字符串或监视实习字符串的增长率。我不相信有任何东西可以监视实习字符串。你也许可以写一些这样的东西，但是这很可能是浪费时间。在一些关键的情况下，字符串会被拘留。最常见的是常量字符串数据，可以是编译到程序集中的字符串，也可以是运行时出于所有目的的静态字符串。一般来说，我不会搞砸.NET的自动实习生管理。如果在处理字符串时看到大量内存使用，那么我更担心的是如何处理字符串，而不是字符串是否被实习生。实习是一个字符串内存使用优化…所以如果字符串实习，他们应该使用更少的内存。但是，动态修改字符串不太可能使用interning。StringBuilder显然是最佳选择……通过减少（或消除）内部缓冲区的大小（这需要创建一个新缓冲区并进行复制），创建具有较大初始容量的构建器可以帮助提高内存使用率。我们目前正在研究的所有好建议。我们担心的是，一个较低级别的API在我们不知情的情况下调用string.intern，并且intern哈希表在我们继续处理文件时呈指数级增长，这是因为用于存储内部字符串的哈希表从未被收集（即，它的CLR范围）。我们在应用程序上安装了一个探查器来解决瓶颈问题。希望我们能找到记忆增长的源头。谢谢你的反馈。