c# - 使用字符串实习来减少网络客户端的内存使用

Question

我有一个处理来自服务器的数据的网络客户端。

数据作为一系列消息发送，它本身是键/值集合，在概念上类似于 HTTP header (除了没有“消息正文”)，这是一个典型的单向消息(由 \r\n 分隔的行) :

Response: OK
Channel: 123
Status: OK
Message: Spectrum is green
Author: Gerry Anderson
Foo123: Blargh

我的协议(protocol)客户端通过使用 NetworkStream 和 StreamReader 逐个字符地读取 while( (nc = rdr.Read()) != -1 ) 来工作，并使用状态机解析器和 StringBuilder 实例来填充 Dictionary<String,String> 实例。然后将这些 Dictionary 实例保存到内存结构中以供进一步处理，它们通常每个都有大约 10 分钟的有用生命周期。

我的客户端每小时收到数千条这样的消息，并且客户端进程是持久的——这是一个问题，因为我的客户端进程经常增长到消耗超过 2GB 的内存，所有这些都来自这些 String 实例——我使用 windbg 来查看所有这些消息在哪里内存正在发生。这是一个问题，因为代码在只有 3.5GB 内存的 Azure VM 上运行。我看不出为什么我的程序最多应该消耗超过几百 MB 的 RAM。通常我会照看 VM 并观察我的进程随时间消耗的内存，它会稳步增长到大约 2GB，然后随着 GC 执行其收集运行而突然下降到大约 100MB，然后它会再次增长。每次 GC 运行的时间可能不同，完全没有可预测性。

因为这些字符串中有很多是相同的(例如键 Response 、 Status 等)以及已知值，例如 OK 和 Fail 我可以使用字符串实习来减少使用，如下所示:

// In the state-machine parser after having read a Key name:

String key = stringBuilder.ToString();
key = String.Intern( key );

// etc... after reading value
messageDictionary.Add( key, value );

问题是我看到了额外优化的空间:sb.ToString() 将分配一个新的字符串实例，用于实习，其次:实习字符串在应用程序域的生命周期内持续存在，不幸的是一些键被赢了看不到重用，实际上会浪费内存，例如我的协议(protocol)示例中的 Foo123。

我认为的一个解决方案是不使用字符串驻留，而是使用一个包含 static readonly 字符串字段的类，这些字符串字段是已知键，然后使用普通的非驻留字符串——最终会被 GC 处理，因此不会冒填满的风险带有一次性字符串的字符串实习生池。然后我会将 StringBuilder 实例与这些已知字符串进行比较，如果是这样，则使用它们而不是调用 sb.ToString() 从而跳过另一个字符串分配。

但是，如果我确实选择对每个字符串进行实习，实习生池将继续增长，不幸的是.NET 似乎没有字符串池的 .Chlorinate() 方法，有没有办法删除一次性字符串如果我继续使用 String.Intern 方法，从实习生池中获取，还是我最好使用自己的静态只读字符串实例？

Answer 1

出于您所引用的原因，实习在这里无济于事。这实际上会使事情变得更糟，因为驻留字符串不再受垃圾收集的影响。不，没有方法可以从池中删除驻留字符串。

您描述的 GC 完全按照 GC 的设计目的执行，因此我不太清楚您是否确实遇到了问题。采用实习意味着用垃圾回收(这不是问题)来换取不断增长的内存需求(这是问题)。

如果您担心 GC 的运行频率不足以将内存消耗保持在您考虑的某个阈值以下，您可以考虑监控内存使用情况并在达到该阈值时调用 GC.Collect()。

如果 GC 的行为模式确实导致了问题(除了看起来很奇怪)，那么您可能想尝试从默认的“工作站”GC 模式切换到“服务器”GC 模式，因为它们的调整方式不同。 (但是，再一次，我完全不相信你确实有问题。)

这两个页​​面涵盖了一些差异:

http://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx#workstation_and_server_garbage_collection

http://blogs.msdn.com/b/dotnet/archive/2012/07/20/the-net-framework-4-5-includes-new-garbage-collector-enhancements-for-client-and-server-apps.aspx

但请注意，实际差异会随着框架的每次发布而变化，因为负责这些内容的人员一直在学习和改进。

GC 模式由应用程序配置控制:

http://msdn.microsoft.com/en-us/library/cc165011(v=office.11).aspx

<configuration
   <runtime>
      <gcServer enabled="true"/>
   </runtime>
</configuration> 

您可能还会发现此故障排除指南很有用，或者至少很有趣:

http://msdn.microsoft.com/en-us/library/ee851764(v=vs.110).aspx#Issue_TooMuchMemory