WPF C# 大文件长字符串拆分OutOfMemory异常及性能优化问询

问题根因分析 #

• 原有Split方案爆内存：读取整行到内存后拆分，会同时在内存中存留整行原始字符串、拆分后的两个子字符串，单条500MB的行内存峰值可达1.5GB以上，32位进程会直接触发OOM，64位进程也容易超过内存配额。
• 现有逐字符读取方案性能差的核心原因：
  1. 单字符读取触发海量IO请求，磁盘IO开销占比超过99%
  2. 每次数组仅扩容1位，触发海量内存拷贝操作，CPU开销极高
  3. StreamReader未手动释放，存在文件句柄泄漏问题

优化方案 #

方案一：流式读取拆分（不改现有文件结构） #

用固定大小缓冲区+StringBuilder减少IO和内存拷贝开销，性能较现有实现提升至少1000倍，代码示例如下：

// 返回值：(base64内容, 文件名)，如果没有文件名则第二项为null，行不存在返回null
public static (string Base64Part, string FileNamePart)? ReadLineParts(string path, int skipLines = 0, int bufferSize = 16384)
{
    using var reader = new StreamReader(path, bufferSize: bufferSize);
    int skipped = 0;
    var base64Builder = new StringBuilder();
    var fileNameBuilder = new StringBuilder();
    bool foundSeparator = false;

    Span<char> buffer = stackalloc char[bufferSize];
    int readCount;

    while ((readCount = reader.Read(buffer)) > 0)
    {
        for (int i = 0; i < readCount; i++)
        {
            char c = buffer[i];
            // 还在跳过目标行之前的内容
            if (skipped < skipLines)
            {
                if (c == '\n') skipped++;
                continue;
            }
            // 读到行尾直接结束读取
            if (c == '\n' || c == '\r')
            {
                // 兼容Windows \r\n 换行格式
                if (c == '\r' && i + 1 < readCount && buffer[i + 1] == '\n') i++;
                goto EndOfLine;
            }
            // 还没找到base64和文件名的分隔空格
            if (!foundSeparator)
            {
                if (c == ' ')
                {
                    foundSeparator = true;
                    continue;
                }
                base64Builder.Append(c);
            }
            // 已找到分隔符，读取文件名部分
            else
            {
                fileNameBuilder.Append(c);
            }
        }
    }
EndOfLine:
    // 跳行数超过文件总行数，返回空
    if (skipped < skipLines) return null;
    return (base64Builder.ToString().Replace(specSymbol, ' '), 
        fileNameBuilder.Length > 0 ? fileNameBuilder.ToString().Replace(specSymbol, ' ') : null);
}

如果base64内容后续要直接转字节数组，还可以进一步优化：不用把base64存为字符串，直接边读边做base64解码，内存峰值可以再降40%左右。

方案二：新增索引文件（可修改文件结构时最优） #

如果可以调整存储逻辑，建议新增独立的索引文件，存储每一行的base64起始偏移、base64长度、文件名。后续读取第N行时，直接查索引获取偏移，用Stream.Seek跳转到对应位置直接读即可，不需要逐行计数换行，速度可以再提升1-2个量级，尤其适合随机读取任意行的场景。

原有逻辑适配 #

拿到返回结果后可以直接替换原有Split逻辑：

var lineParts = ReadLineParts(resPath, currentRow);
if (lineParts == null)
{
    // 自行补充行不存在的处理逻辑
    return null;
}
string base64 = lineParts.Value.Base64Part;
try
{
    if (!IsVideo(ref base64) && !IsGif(ref base64))
    {
        ShowPrimary();
        imgFile.Source = BytesToBitmap(Convert.FromBase64String(base64));
    }
    else
        btnLoadFile.Background = readyColor;
    return lineParts.Value.FileNamePart;
}
catch (Exception ex) 
{ 
    MessageBox.Show($"Next(4):{ex.Message}"); 
    return null;
}

内容的提问来源于stack exchange，提问作者GeekProgrammer