处理大量文本时防止内存问题

Question

我编写了一个程序，用于分析项目的源代码，并根据代码报告各种问题和指标。

为了分析源代码，我加载了项目目录结构中存在的代码文件，并从内存中分析代码。代码在传递给其他方法进行进一步分析之前会经过大量处理。

代码在处理时传递给几个类。

有一天，我在我的小组的一个较大的项目上运行它，我的程序因为有太多的源代码加载到内存中而瘫痪了。这是一个极端的案例，但我希望将来能够处理这个问题。

避免内存问题的最佳方法是什么？

我正在考虑加载代码，对文件进行初始处理，然后将结果序列化到磁盘，这样当我需要再次访问它们时，我不必经历操作原始的过程代码再次。这有意义吗？或者序列化/反序列化比再次处理代码更昂贵？

我希望在解决此问题时保持合理的性能水平。大多数情况下，源代码会毫无问题地适应内存，所以当我内存不足时，有没有办法只能“分页”我的信息？有没有办法告诉我的应用程序何时内存不足？

更新： 问题不在于单个文件填充内存，其内存中的所有文件都会立即填充内存。我目前的想法是在处理磁盘驱动器时将其旋转

Answer 1

1.6GB仍然可以管理，本身不应该导致内存问题。低效的字符串操作可能会这样做。

在解析源代码时，您可能会将其拆分为某些子字符串 - 令牌或您称之为的内容。如果您的令牌合并了整个源代码，那么内存消耗就会增加一倍。根据您处理的复杂程度，mutiplier可能会更大。 我在这里的第一步是仔细看看你如何使用你的字符串并找到一种方法来优化它 - 即在第一次传递后丢弃原始数据，压缩空格，或者使用索引（指针）到原始字符串而不是实际的子串 - 有许多技术在这里很有用。

如果这些都没有帮助，那么我会把它们交换到磁盘上

Answer 2

如果问题是您的代码的单个副本导致您填充可用内存，那么至少有两个选项。

• 序列化为磁盘
• 压缩内存中的文件。如果你有很多CPU，可以更快地在内存中压缩和解压缩信息，而不是缓存到磁盘。

您还应该检查是否正确处理了物体。由于对象的旧副本在内存中，您是否有内存问题？

Answer 3

将WinDbg与SOS一起使用，以查看字符串引用的内容（或导致极端内存使用的原因）。

Answer 4

序列化/反序列化听起来像是一个好策略。我已经做了相当多的这个并且它非常快。事实上，我有一个应用程序，它从数据库中实例化对象，然后将它们序列化到我的Web节点的硬盘驱动器。自从我对它进行基准测试以来已经有一段时间了，但是当我进行负载测试时，它的序列化数百秒，可能超过1k。

当然，这取决于代码文件的大小。我的档案相当小。