【发布时间】：2021-05-27 01:30:08
【问题描述】：
最近在面试中被问到，C#中的字符串能不能来LOH。面试官提到GC逻辑有一些优化，将一个大字符串拆分成几个较小的字符串，所以这个字符串永远不会到达LOH。
我没有在 MSDN 文章中找到相关信息： https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/large-object-heap 和 https://docs.microsoft.com/en-us/archive/msdn-magazine/2008/june/clr-inside-out-large-object-heap-uncovered
那么对于在 LOH 中存储字符串，CLR 有什么影响或优化吗？它是否与字符串实习有关？
【问题讨论】：
-
我会回答这是一个非常具体的实现细节，极少人会知道，除了少数几个边缘情况外，它很可能在所有情况下都没有显着的性能.了解 C# 如何在底层工作是一项有用的奖励技能，但不如了解编写优秀软件的“高级”概念重要。
-
在面试中听到这样的问题我很惊讶，这就是为什么我想仔细检查面试官的看法是否正确
-
我正在给一个关于 GC 的非正式内部课程。为了创建垃圾，我有一个
List<string>，我在其中添加了count的new string('*', allocationSize)实例。allocationSize变量实际上是一个以平均值为中心的随机数。当平均值变得足够大（即 > 85k）时，我观察到了我认为的 LOH 效应。任何参与的人都可能相信我。 -
没有这样的优化。不知道面试官怎么会有这样的想法……
-
可能面试官混淆了
string的实现（它必须是一个连续的缓冲区）和StringBuilder的实现（过去是一个可调整大小的缓冲区，类似于@ 987654329@ 等，但当前是缓冲区的链接列表）。所有这些都是可能随时更改的实现细节，因此对于学术问题来说，真正的实际编程问题并不多。
标签： c# string memory-management garbage-collection large-object-heap