7

我有一个 .NET 3.5 应用程序

  • 一个函数运行一百万次
  • 它在 1MB+ 字符串（不同大小的字符串）中进行搜索、替换和正则表达式操作

当我分析应用程序时，我可以确认这些字符串存储在 LOH 中，但它们稍后也会被 GC 回收，因此在给定时间，其中最多只有 10 个在 LOH 中（10 个线程正在运行）。

我的理解是，这些大字符串位于 LOH 中，然后被 GC 回收，但不知何故由于它们的分配位置（并且在 LOH 中因此没有被压缩），这会导致碎片。尽管操作中没有内存泄漏，但仍会发生这种情况。

它不会在大约 100K 次内引起问题，但是当它达到 1M+ 时，它会出现内存不足的异常。

我正在使用 ANTS Memory Profiler，这是我在早期执行中得到的结果：

.NET Using 70MB of 210MB total private bytes allocated in to the application
Number of Fragments: 59
Number of Large Fragments : 48 (99.6% of free memory)
Largest Fragment: 9MB
Free Space: 52% of total memory  (37MB)
Unmanaged Memory: 66% of total private memory (160MB)
  1. 根据手头的数据，你认为我的诊断是正确的吗？
  2. 如果是这样，我该如何解决这个 LOH 碎片问题？我必须处理这些字符串，它们是大字符串。我应该找到一种方法将它们分开并像这样处理吗？在这种情况下，在拆分字符串中运行正则表达式等将非常具有挑战性。
4

1 回答 1

2

  1. 是的。听起来是对的。LOH 变得碎片化，这导致运行时无法为大字符串分配足够的连续空间。

  2. 你有几个选择，我想你应该选择最简单和有效的那个。这完全取决于它的写作方式。

    1. 将你的字符串分成足够小的块，它们不在 LOH 中。（小于 85K - 注意：将对象放在 LOH 上的逻辑并不那么简单。）这将允许 GC 能够回收空间。这决不能保证修复碎片 - 否则它肯定仍然会发生。如果你把琴弦做得更小，但仍然在 LOH 上——你会推迟问题。这取决于您需要处理多少超过 100 万个字符串。另一个缺点是 - 您仍然必须将字符串加载到内存中才能拆分它，因此无论如何它最终都会出现在 LOH 上。在您的应用程序甚至加载它们之前，您将缩小字符串。有点像第 22 条军规。编辑：Gabe 在评论中指出，如果你可以将你的字符串加载到StringBuilder第一个，那么在幕后它会努力将事情排除在 LOH 之外（直到你调用ToString它）。

    2. 将字符串的处理分成一个单独的过程。使用进程而不是线程。使用每个进程处理 10K 个字符串，然后终止该进程并启动另一个。这样，每个过程都从一张白纸开始。这样做的好处是它不会改变你的字符串处理逻辑（以防你不能让你的字符串更小以便处理），并且避免了 #1 中的 catch-22。缺点是这可能需要对您的应用程序进行更大的更改，并协调主进程和从属处理进程之间的工作。诀窍是主人只能告诉它大字符串在哪里，它不能直接给它，否则你又回到了catch-22。

于 2011-09-11T02:55:11.293 回答