Como Ler Arquivos CSV Pesados em C# sem Travar a Memória

Quem trabalha com integração de sistemas, exportação de relatórios ou importação de dados em massa já passou por isso: você precisa processar um arquivo CSV de centenas de megabytes (ou até gigabytes) e a aplicação simplesmente trava, consome toda a RAM do servidor ou lança a famosa exceção OutOfMemoryException.

O motivo clássico para isso acontecer é o uso inocente de rotinas que tentam carregar o arquivo inteiro para a memória antes de processar. E eu sei bem como é isso.

Eu particularmente adoro manipular arquivos com programação. Já falei sobre isso no post Como Aplicações Simples Podem Ser Poderosas, onde mostro C# manipulando arquivos TXT e scripts BAT. Não sei explicar o motivo, mas realmente adoro esse tema de ler arquivos, alterar, incluir dados. Foi o que me motivou a escrever este post.

Neste artigo, vamos entender por que o File.ReadAllLines trava e qual é a abordagem correta usando C# para processar arquivos gigantescos de forma rápida, estável e com consumo de memória praticamente zero.

Quando precisamos ler um arquivo texto, a primeira ideia costuma ser usar o método File.ReadAllLines():

// EVITE ISSO PARA ARQUIVOS GRANDES!
string[] linhas = File.ReadAllLines(@"C:\dados\relatorio_gigante.csv");

foreach (string linha in linhas)
{
    // Processamento da linha
}

Esse código parece inofensivo, mas tem um problema grave: ele carrega o arquivo inteiro na memória antes de você processar a primeira linha [Stack Overflow].

Em um arquivo de 225MB, por exemplo, o processo pode chegar a consumir mais de 1GB de RAM [Stack Overflow]. Isso acontece porque:

• O arquivo é lido por completo em um string[];
• Cada linha vira uma string na memória;
• Ao mesmo tempo, o encoding e os objetos intermediários também ocupam espaço;
• Se o arquivo tiver 500MB, você pode facilmente estourar 2GB de RAM.

A documentação da Microsoft é clara: "Quando você usa ReadAllLines, você precisa esperar que todo o array de strings seja retornado antes de acessá-lo. Portanto, ao trabalhar com arquivos muito grandes, ReadLines pode ser mais eficiente" [Stack Overflow].

O jeito mais simples de resolver o problema sem trocar quase nada no código é usar File.ReadLines() em vez de File.ReadAllLines().

A diferença crucial: File.ReadLines retorna um IEnumerable<string> que lê uma linha por vez, sob demanda [Stack Overflow].

// Use ISSO para arquivos grandes
foreach (string linha in File.ReadLines(@"C:\dados\relatorio_gigante.csv"))
{
    // Processamento da linha
    // A memória usada aqui é apenas a da linha atual
}

Com essa mudança simples, o consumo de memória cai de centenas de megabytes para poucos kilobytes [Stack Overflow].

Quando isso não é suficiente? Quando o arquivo tem campos com quebras de linha internas. Nesse caso, uma linha "lógica" do CSV pode conter \r\n dentro de um campo entre aspas, e o ReadLines vai dividir errado [Stack Overflow].

Para ter controle total sobre a leitura, encoding e buffer, o StreamReader é a escolha profissional. Ele lê o arquivo em blocos (buffer) e mantém apenas o necessário em memória.

using (var reader = new StreamReader(@"C:\dados\relatorio_gigante.csv"))
{
    string linha;
    while ((linha = reader.ReadLine()) != null)
    {
        // Processamento da linha
        // Apenas a linha atual está na memória
    }
}

E a versão assíncrona, para não bloquear a thread principal:

using (var reader = new StreamReader(@"C:\dados\relatorio_gigante.csv"))
{
    string linha;
    while ((linha = await reader.ReadLineAsync()) != null)
    {
        // Processamento assíncrono
    }
}

A documentação da Microsoft destaca que o StreamReader é a forma mais eficiente de ler arquivos grandes, pois trabalha com streaming em vez de carregar tudo de uma vez [Stack Overflow].

Vantagens do StreamReader:

• Controle de encoding: você define UTF-8, GB2312, Latin1, etc.;
• Buffer configurável: pode ajustar o tamanho do buffer para otimizar I/O;
• Async nativo: ReadLineAsync() libera a thread durante a leitura;
• Memória mínima: apenas o buffer e a linha atual ocupam espaço.

Se o seu CSV é "bagunçado" — com campos entre aspas, vírgulas dentro de valores ou quebras de linha internas — aí o Split(',') não resolve. Você precisa de um parser de verdade.

A biblioteca mais popular do ecossistema .NET é o CsvHelper. Mas atenção: usar CsvHelper do jeito errado também causa OutOfMemoryException [php.cn].

O erro clássico é chamar ReadRecords<T>(), que carrega todo o arquivo na memória antes de retornar [php.cn].

// EVITE: ReadRecords carrega tudo na memória
var records = csv.GetRecords<MeuModelo>().ToList();

A forma correta é usar GetRecord<T>() dentro de um loop com Read() explícito [php.cn]:

using (var reader = new StreamReader("input.csv"))
using (var csv = new CsvReader(reader, CultureInfo.InvariantCulture))
{
    // Lê o header primeiro
    csv.Read();
    csv.ReadHeader();

    // Agora lê linha por linha
    while (csv.Read())
    {
        var record = csv.GetRecord<MeuModelo>();
        // Processamento
    }
}

Um detalhe importante: em versões mais antigas do CsvHelper, a checagem de ShouldSkipRecord fazia o parser materializar a linha duas vezes — uma para checar e outra para você ler. Isso dobrava o consumo de memória [GitHub].

A boa notícia é que isso foi corrigido. Se você está usando uma versão recente, o impacto é mínimo. Se estiver preso a uma versão antiga, saiba que isso pode ser o gargalo.

Se você precisa de performance extrema — estamos falando de ler múltiplos gigabytes por segundo — vale conhecer o FlameCsv.

Segundo a própria documentação, o FlameCsv foi construído do zero com Span<T>, SIMD e MemoryPool para oferecer "near-zero allocations" [NuGet].

O que isso significa na prática?

• Zero pressão no Garbage Collector para arquivos enormes;
• Parsing com aceleração por hardware (AVX2/SSE2);
• Suporte a UTF-8 nativo, sem conversão intermediária;
• Leitura e escrita assíncronas.

O código é simples:

using FlameCsv;

await foreach (var record in CsvReader.ReadAsync<MeuModelo>("dados.csv"))
{
    // Processamento com alocação próxima de zero
}

Quando usar FlameCsv? Quando o volume de dados é tão grande que o CsvHelper já não dá conta. Para a maioria dos casos do dia a dia, o CsvHelper é suficiente. Mas se você está processando milhões de linhas diariamente, vale testar.

Não adianta só confiar no gerenciador de tarefas. Em C#, você pode medir o consumo real da sua aplicação com a classe Process [Learn Microsoft].

A propriedade PeakWorkingSet64 retorna o pico de memória física (em bytes) usado pelo processo desde que ele foi iniciado [Learn Microsoft].

using System.Diagnostics;

var processo = Process.GetCurrentProcess();
long picoMemoriaBytes = processo.PeakWorkingSet64;
double picoMemoriaMB = picoMemoriaBytes / (1024.0 * 1024.0);

Console.WriteLine($"Pico de memória: {picoMemoriaMB:F2} MB");

Como usar isso no seu teste:

1. Meça o pico usando File.ReadAllLines com um CSV de 200MB;
2. Meça o pico usando File.ReadLines com o mesmo arquivo;
3. Meça o pico usando StreamReader;
4. Compare os três resultados.

Você vai ver uma diferença brutal. O ReadAllLines pode consumir 500MB a 1GB, enquanto o StreamReader fica na casa dos kilobytes.

Não existe "bala de prata", mas existe a abordagem certa para cada cenário:

A regra de ouro é simples: nunca carregue um arquivo inteiro na memória se você pode processar linha a linha. O File.ReadAllLines é uma armadilha para arquivos grandes, e o StreamReader é seu melhor amigo.

E aí, você já passou por esse problema? Qual foi a solução que você adotou? Conta pra gente nos comentários.

Quer dominar C# e .NET de verdade?

No Nerd Cult, a gente descomplica o desenvolvimento — da leitura de arquivos à arquitetura de sistemas. Assine nossa newsletter e receba conteúdos práticos direto no seu e-mail.

QUERO RECEBER OS GUIAS

Bônus: Checklist de performance para aplicações .NET

Nerd Cult — onde o código encontra o rock, o cinema e a cultura geek. Porque ser nerd é transformar o medo em curiosidade, e a curiosidade em poder.

#CSharp #DotNet #CSV #Performance #StreamReader #NerdCult