Para começar, quero deixar bem claro um ponto: não utilize o Gerenciador de Tarefas, em hipótese alguma, para falar sobre memória. Ele não diz quanto de memória é usada pela sua aplicação, não serve pra determinar se alguém está vazando memória, nem mesmo se uma aplicação utiliza mais memória que a outra.

A informação que é passada na coluna de uso de memória, no gerenciador de tarefas, é o Working Set. Working Set de um processo é o conjunto de páginas de memória fisica atualmente reservadas para este processo. Se a memória que sua aplicação está usando é menor que o Working Set, páginas livres estão disponíveis para atender requisições de alocação de memória rapidamente. Se sua aplicação utiliza mais memória que o Working Set reservado pra ela, parte dessa memória é jogada para o cache em disco – chamado de arquivo de troca, ou swap file. Além disso, o Working Set também soma o tamanho de DLLs carregadas, inclusive as de sistema, mesmo que estejam sendo compartilhadas por vários processos. Memory Mapped Files também contam como páginas para o Working Set mesmo não utilizando um byte de memória.

O Windows geralmente mantém reservadas no Working Set mais páginas do que a aplicação utiliza no momento, para que aplicações façam menos swap e tenham uma performance melhor quando precisarem alocar mais memória. Afinal, memória não alocada é memória desperdiçada, e quando for necessário mais memória do que está livre fisicamente, os working sets são diminuídos conforme for necessário.

Além de quando o Windows tem pressão de memória, o Working Set de uma aplicação geralmente também é diminuído quando a aplicação é minimizada. É fácil fazer o teste: pegue uma aplicação que você está usando faz algum tempo, olhe o Working Set dela no gerenciador de tarefas, minimize essa aplicação e veja como o Working Set diminuiu. A aplicação utiliza a mesma quantidade de memória que utilizava antes de ser minimizada, mas agora possui menos memória reservada para ela (e corre risco maior de cair no swap se a memória fisica estiver curta).

Uma terceira forma de diminuir o Working Set de uma aplicação é chamar a API SetWorkingSetSize(); para zerar o Working Set de uma aplicação, tendo o mesmo efeito de minimizá-la. Apesar de o propósito útil da API seja reservar um Working Set maior que o atual para evitar constante swaping ao realocar memória frequentemente, muita gente utiliza a API para o contrário, muita vezes em um timer, para manter os números sua aplicação no Gerenciador de Tarefas bonitos e aparentemente baixos. O resultado prático disso é, obviamente, uma maior lentidão para alocar memória e maior proabilidade de sua aplicação entrar no swap.

A decisão de manter o working set quando minimizado está documentada em páginas e páginas de discussão no bug que corrigiu o demorado reínicio após um grande período de inatividade. Um comentário no código fonte do Firefox diz que se alguém reclamar do uso de memória do Firefox quando minimizado, vai ter a discussão completa sobre o bug tatuada nas costas. Espero que, entendendo o que é o Working Set, você não corra esse risco.

A partir do Delphi 2006 o gerenciador de memória padrão que acompanha o Delphi passa a ser o FastMM. Quem não trabalha com Delphi 2006 pode baixar o FastMM aqui.

Se você estiver começando agora a desenvolver com Delphi deve estar se perguntando: Tá, e dai? O que é memory leak?

Memory leak é um objeto criado pela aplicação que não foi corretamente destruído.

Você pode simular esta situação criando qualquer objeto no OnCreate do formulário principal da sua aplicação. Exemplo:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally

  end;
end;

Execute o aplicativo e feche-o. Você notará que não acontece nada!

Esse teste ridículo foi feito só para você ver como é comum ocorrerem problemas que resultem em vazamentos de memória (memory leaks) como a falta de atenção (nesse caso), a pressa, Control+C / Control+V entre alguns outros.

Agora insira esta linha logo após o begin da sua procedure:

ReportMemoryLeaksOnShutdown := True;

Deixando o código assim:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally

  end;
end;

Repita a operação e veja o que acontece após fechar o aplicativo:

Veja que recebemos a notificação do TStringList que criamos e das 3 linhas que adicionamos (String x 3) a ele. A partir dai podemos começar a evitar esse tipo de erro na hora de desenvolvermos aplicativos.

Uma dica importante é você utilizar o bloco try…finally…end; sempre que criar um objeto dinamicamente. Isto evita que ocorra um erro no meio da execução e ele não seja destruído devidamente. Veja os dois exemplos:

Método não apropriado:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  lstVazamento.Add('Linha 1');
  lstVazamento.Add('Linha 2');
  lstVazamento.Add('Linha 3');
  lstVazamento.Free;
end;

Método apropridado de utilização:

procedure TForm1.FormCreate(Sender: TObject);
var
  lstVazamento : TStrings;
begin
  ReportMemoryLeaksOnShutdown := True;

  lstVazamento := TStringList.Create;
  try
    lstVazamento.Add('Linha 1');
    lstVazamento.Add('Linha 2');
    lstVazamento.Add('Linha 3');
  finally
    lstVazamento.Free;
  end;
end;

Utilizando o bloco try…finally…end; mesmo que ocorra algum erro na execução do procedimento o objeto é destruído. Pelo método não apropriado lstVazamento não seria destruído caso ocorresse algum problema na execução da linha lstVazamento.Add(‘Linha 1′);, por exemplo.

Em tempo: utilizando ReportMemoryLeaksOnShutdown := True; a mensagem ocorrerá sempre que o aplicativo for terminado, inclusive fora do Delphi. Para evitarmos esse situação, substitua o True por DebugHook <> 0; deixando a linha assim:

ReportMemoryLeaksOnShutdown := DebugHook <> 0;

Para quem utiliza outras versões do Delphi isto deve ser configurado no arquivo FastMM4Options.inc.

No próximo artigo abordaremos mais funções do FastMM e configurações do arquivo FastMM4Options.inc para quem utiliza FastMM em versões mais antigas do Delphi. Até mais!

Exemplo: seu programa utilizou 4.569K e liberou 169K, esse valor é contabilizado pelo windows até que outro programa o utilize (o gerenciador continua mostrando os 4.569K).

A causa desse problema com o gerenciador de tarefas é o gerenciador de memória runtime do Delphi alocar memória indiretamente. Quando o programa solicita memória para o gerenciador, ele aloca blocos de memória para o programa. Os blocos tem tamanho fixo de modo que para cada pedido de memória o gerenciador aloca a quantidade necessária de blocos contínuos para satisfazer o pedido do programa.

Deste ponto de vista o bloco é a menor quantidade de bytes que o gerenciador aloca.

Exemplo: Um bloco tem 16 bytes; se o programa pede 4 bytes, o gerenciador irá alocar um bloco; se o programa pedir 18 bytes, o gerenciador irá alocar dois blocos.

Parece que o gerenciador está “torrando” memória a toa, mas isso é feito para evitar a fragmentação da memória. Quando o programa devolve memória ao gerenciador, este não a devolve para o Windows, pois ele deduz que o programa pode solicitar mais memória a qualquer momento e a reserva para otimizar o tempo de acesso a ela.

Entendendo melhor o funcionamento:

Imagine que você possui duas classes (TAlocaMemoriaAtoa e TAlocaMemoriaAVontade). Quando executamos um programa qualquer, por exemplo, vamos imaginar que o gerenciador aloque 10 blocos de memória. Após isso criamos a classe TAlocaMemoriaAtoa que solicita ao gerenciador mais 10 blocos. O tamanho total de memória utilizada é 20 blocos. Ao destruírmos a classe TAlocaMemoriaAtoa o sistema libera 10 blocos, mas o gerenciador os mantém disponíveis para a aplicação. Se nesse momento criarmos a classe TAlocaMemoriaAVontade e esta solicita 5 blocos de memória, o gerenciador buscará 5 blocos dos 10 reservados anteriormente, quando a classe TAlocaMemoriaAtoa fora destruída.

BINGO! Por isso que quando eu fazia debug da minha aplicação com o gerenciador de tarefas aberto os “Free” e “FreeAndNil” quase nunca funcionavam!

No meu próximo post falarei sobre gerenciadores de memória alternativos como o FastMM, adotado como gerenciador de memória padrão na versão 2006 do Delphi, e faremos alguns testes comparativos. Até a próxima.