Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Lidando com Vazamentos de Memória no .NET
Postado por Abel Avram , traduzido por Yan Borowski em 12 Nov 2009
Fabrice Marguerie, um arquiteto de software e consultor, escreveu o artigo Como detectar e evitar vazamentos de memória e recursos de aplicações. NET, publicado no MSDN. O artigo explica como vazamentos de memória e recursos podem acontecer durante a programação para. NET e como evitá-los.
Linguagens como C #, fazendo a limpeza da casa através de um coletor de lixo de memória, não tem vazamentos de memória em seu sentido original quando perde um programa de acesso completo a um local de memória. Segundo Fabrice, vazamentos de memória ocorrem quando uma localização de memória já não é necessária, mas o programa continua a manter pelo menos uma referência a ele. O coletor de lixo iria reclamar que a memória se era inacessível, mas a memória se torna um vazamento, desde que ela é referenciada pelo programa e não é mais utilizada.
Fabrice também enumera uma série de recursos de sistema operacional que podem ser sujeitos a vazamentos similares:
- O sistema utiliza objetos do usuário para suportar o controle da janela. Eles incluem: aceleradores de tabela, Carets, Cursores, Hooks, ícones, menus e janelas.
- Suporte a Objetos GDI gráficos: Bitmaps, Brushes, Contextos de dispositivo (DC), Fontes, DCs de memória, Metafiles, paletas, canetas, Regiões, etc
- Objetos do Kernel de apoio para gerenciamento de memória , execução do processo e inter-processo de comunicação (IPC): arquivos, processos, threads, semáforos, temporizadores, tokens de acesso, Sockets, etc
Estes recursos são limitados, as chaves do Registro GDIProcessHandleQuota e USERProcessHandleQuota contendo o número máximo de objetos de usuário e GDI que um processo pode usar. Os valores padrão são 10.000 para estas alças. Embora este número seja suficiente para a maioria das aplicações, a utilização de muitas delas fará com que o sistema atinja outro limite de 65.536 alças para uma sessão do Windows. Fabrice relatou que bateu este limite muito mais cedo, em cerca de 11.000.Sua conclusão é que os recursos de sistemas devem ser cuidadosamente utilizados e liberados quando não mais necessários.
Fabrice enumera as seguintes causas de vazamentos, explicando como funciona cada um deles:
- Usando referências estáticas
- Evento com a falta de cancelamento - essa é considerada, pelo autor, como a fonte mais comum de vazamentos
- Evento estático com a falta de cancelamento da referência
- Não chamar o método Dispose
- Usando um método Dispose incompleto
- A utilização indevida BindingSource com Windows Forms
- Não usar a chamada Remove no WorkItem/CAB
O autor continua o artigo, oferecendo aconselhamento sobre como evitar vazamentos:
- O criador ou proprietário de um objeto, e não o seu utilizador, é responsável pelo escoamento
- Sempre remova a referência de um Event Listener quando a mesma não é mais necessária, isso poderia ser feito com o Dispose() para a segurança
- Quando um objeto não gera mais eventos, todos os seus Listeners devem ser removidos através da atribuição de "null" para o objeto
- Quando uma referência é usada por um Model e pela sua View, é recomendado passar um clone do objeto referenciado para a View, evitaando assim que se perca quem está usando o que
- Chamadas aos recursos do sistema devem ser colocadas em blocos com "using" que forçam automaticamente uma chamada Dispose, ao sair do bloco
Fabrice conclui pela introdução de uma série de ferramentas úteis para lidar com objetos e vazamentos: GDILeaks (EXE), dotTrace, .NET Memory Profiler, SOS.dll, WinDbg.
Nenhum comentário
Acompanhar Discussão Responder