【问题标题】:Large string array causing out of memory exception (C#)导致内存不足异常的大字符串数组(C#)
【发布时间】:2012-02-03 07:13:33
【问题描述】:

我编写了一个 c# win forms 应用程序,它允许用户打开一个日志(文本)文件并查看数据网格中的日志行。记录数据的应用程序格式,以便用户可以过滤、搜索等。

我遇到的问题是,当用户打开大于 300mb 的日志文件时,应用程序会抛出内存不足异常。

应用程序首先将所有日志行加载到一个字符串数组中,然后遍历日志行,将日志条目对象添加到列表中。

var allLogLines = File.ReadAllLines(logPath).ToList();
var nonNullLogLines = allLogLines.Where(l => !string.IsNullOrEmpty(l));

this.ParseLogEntries(nonNullLogLines.ToArray());

这个初始步骤(将日志数据加载到字符串数组中)在任务管理器中占用了大约 1gb 的内存。

internal override void ParseLogEntries(string[] logLines)
{
    this.LogEntries = new List<LogEntry>();
    this.LogLinesCount = logLines.Count();

    for (int i = 0; i < this.LogLinesCount; i++)
    {
        int entryStart = this.FindMessageCompartment(logLines, i);
        int entryEnd = this.FindMessageCompartment(logLines, entryStart + 1);
        int entryLength = (entryEnd - entryStart) + 1;

        if (entryStart + entryLength > this.LogLinesCount)
        {
            entryLength = this.LogLinesCount - entryStart;
        }

        var logSection = new string[entryLength];

        Array.Copy(logLines, entryStart, logSection, 0, entryLength);
        Array.Clear(logLines, i, entryLength - 1);

        this.AddLogEntry(logSection);

        i = (entryEnd - 1);
    }
}

AddLogEntry 方法将日志条目添加到列表 (LogEntries)。 for 循环设法解析了大约 50% 的日志文件,然后发生内存不足异常。此时任务管理器报告应用程序正在使用大约 1.3gb 的内存。

正如您在上面看到的,我添加了 Array.Clear 以清空已成功解析的日志数据部分,因此我希望随着对象被添加到集合中,内存量 (大型日志数据阵列使用的 1gb 会稳步减少,但不会。实际上,即使我定期添加 GC 收集,这行代码对内存使用量也没有影响。

在阅读了 LOH 之后,我假设这是因为堆没有被压缩,因为大型数组的一部分被清空了,所以不管它的内容如何,​​它总是使用相同的 1gb 内存。

有什么方法可以减少在解析数据时占用的内存量,或者可能的返工可以更好地利用内存?一个 300mb 的文本文件在放入字符串数组时会消耗 1gb 的内存,这对我来说似乎很奇怪?

谢谢。

【问题讨论】:

  • 什么是FindMessageCompartment?也不要使用数组,使用泛型List&lt;string&gt;
  • 是否有任何问题在做 ReadLine,即逐行读取和处理文件?而不是一次全部加载。
  • 这是否发生在您显示数据之前,就在解析期间?
  • 你如何阅读你的文件你使用 StramReader.ReadLine() 吗?
  • .NET 的哪个版本? .NET 4 为枚举文件行提供了有效的方法,而无需获取内存中的所有行

标签: c# memory out-of-memory heap-memory


【解决方案1】:

您可以使用 ParseLogEntry(string logLine) 方法代替一次性解析所有日志行的方法 ParseLogEntries(string[] logLines)

如果您将此与一次遍历日志文件中的行相结合(例如,通过为自己创建一个 enumerator),这将避免首先创建大数组 string[] logLines

一种方式可能是这样的:

static IEnumerable<string> ReadLines(string filename)
{
    using (TextReader reader = File.OpenText(filename))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            yield return line;
        }
    }
}

// And use the function somewhere to parse the log

var logEntries = new List<LogEntry>()
foreach (string line in ReadLines("log.txt"))
{
    logEntries.Add(ParseLogEntry(line));
}

如果您使用的是 .NET 4.0 或更高版本,您当然可以只使用 sll 在另一个答案中指出的 File.ReadLines 方法,而不是创建自己的方法。

【讨论】:

  • 顺便提一下:ReadLines 方法是我从伟大的 Jon Skeet 的伟大著作 C# In Depth 中学到的;-)
  • 我使用的是 .Net 3.5,Enumerator 看起来是一个理想的解决方案,非常感谢。
【解决方案2】:

我首先看到的是,您正在通过使用以下语句重用和加倍内存使用:

File.ReadAllLines(logPath).ToList();

系统会先读入所有行,然后将其转换为使用量翻倍的List。

我建议您使用以下方式通过流式阅读器读取文件:

using(var sr = new StreamReader(fileName)) { // 在这里获取数据 }

这样,一旦你离开语句,内存就会被处理掉。

另外 Array.Copy 将使用更多内存,因此请尝试在 Using 语句中创建和创建您的 Desired 对象或使您的 Objects IDisposable,这样 GarbageCollector 可以节省时间。

【讨论】:

  • 它使引用的内存使用量增加了一倍,但这与实际的字符串数据(它没有再次分配)相比可能并不多。
【解决方案3】:

我建议不要将所有文件加载到内存中并使用惰性读取。对于 >=.NET 4,您可以利用 File.ReadLines() Method 读取文件。

当你使用 ReadLines 时,你可以开始枚举集合 返回整个集合之前的字符串;因此,当你 正在处理非常大的文件,ReadLines 可以更高效。

foreach (string line in File.ReadLines(@"path-to-a-file"))
{
   // single line processing logic
}

【讨论】:

    【解决方案4】:

    我知道这不会回答您的问题,但您可能需要考虑不将文件完全加载到内存中。

    在您的情况下,您的日志文件需要 300MB 内存,但如果需要 2.5GB 怎么办? 特别是如果结果是在数据网格中显示,您可能希望使用分页代替,并在每次需要时从文件中加载一小块数据。

    【讨论】:

      【解决方案5】:

      字符串需要堆上连续的内存段;当您在堆上有很多长字符串并且您尝试分配另一个字符串但没有所需长度的可用段时,应用程序可能会抛出“内存不足”。

      您的Array.Clear 行可能无济于事,因为logSection 字符串不会被垃圾回收,事实上,随着循环的迭代,运行时会遇到困难,因为很难找到例如 10K 的空间堆比找到 10 个 1K 空间。

      这就是你的问题。至于解决方案,一般来说我会建议一个更懒惰的解决方案。你真的需要主内存中的所有这些字符串吗?如果是,您为什么不至少从StreamReader 中读取,而是将所有内容加载到string[] logLines

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-07-16
        • 2012-12-15
        • 2015-05-31
        • 2014-03-28
        • 2014-03-26
        • 1970-01-01
        相关资源
        最近更新 更多