#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
dê seu feedback
post favorito
Artigo Java Magazine 75 - Gerenciando Memória e Recursos
Conheça as melhores práticas – e as piores – para administrar recursos, prevenir leaks e outros erros.
Java Magazine 75
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 75
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 75
BRK##: 0 - 0
Gerenciando Memória e Recursos
Você acha que devido ao GC, não precisa se preocupar com alocação de memória e outros recursos? Achou errado
Conheça as melhores práticas – e as piores – para administrar recursos, prevenir leaks e outros erros
De que se trata o artigo:
Examinamos os problemas de gerenciamento de memória e de recursos em Java, investigando várias “receitas” de bugs como leaks de memória ou retenção indevida de recursos, e aprendendo a evitar estes problemas.
Para que serve:
O gerenciamento correto e eficiente de memória e recursos é uma necessidade de qualquer aplicação, especialmente aquelas destinadas a executar continuamente durante muito tempo, ou aquelas que devem enfrentar picos de atividade intensa e apresentar boa escalabilidade. Leaks de memória podem resultar em problemas que vão desde mau desempenho até crashes da VM com OutOfMemoryError. Ineficiência no gerenciamento de recursos podem causar problemas difíceis de diagnosticar, como a observação que uma aplicação não consegue escalar acima de uma taxa modesta de transações simultâneas mesmo com o servidor aparentemente pouco carregado.
Em que situação o tema é útil:
Bugs relacionados à alocação de memória e manipulação de recursos são inaceitáveis em sistemas de “missão crítica”, mas devem ser evitados em qualquer tipo de aplicação. Uma das dificuldades de combater tais bugs, especialmente os de gerenciamento de memória, é que devido ao recurso de GC do Java, muitos desenvolvedores dão pouca atenção ao problema, achando que a JVM irá magicamente dar conta do recado. Infelizmente não é tão simples assim; neste artigo, exploramos alguns anti-patterns que com freqüência resultam em leaks de memória e outros problemas.
Na evolução das linguagens de programação, grandes avanços como a técnica de GC (Garbage Collection) são geralmente interpretados como “o fim de todos os seus problemas”, pelo menos de uma ampla categoria como os problemas relacionados ao gerenciamento de memória. Mas no longo prazo essa esperança sempre acaba em decepção, pelo menos parcial, pois nem todos os problemas atacados pela nova tecnologia terminam totalmente. Vamos fazer uma rápida análise dos efeitos da GC, em comparação com linguagens com gerenciamento manual de memória como C/C++:
• Corrupção do heap: totalmente eliminado (devido parcialmente à GC, e parcialmente a outras características de linguagens gerenciadas);
• Leaks de memória: mais raros, mas não eliminados;
• Consumo de memória além do necessário: pouco melhorado. A melhoria vem da programação mais simples, especialmente para objetos com ciclo de vida complexo (referenciados de muitos lugares, alocados e liberados em lugares e momentos distantes). A GC permite a cada parte do código liberar referências para objetos utilizados tão logo estes deixem de ser localmente úteis, e quando não houver mais nenhuma referência, a VM detecta isso e remove o objeto. Já em programas com memória manual, quando é complicado determinar quando um objeto pode ser deletado, isso quase sempre resulta numa retenção muito conservadora do objeto, que só é deletado muito depois do último momento em que foi realmente usado;
• Leaks de recursos: “recursos” são objetos que exigem procedimentos especiais de desalocação, por exemplo a liberação de um socket, conexão de pool, descritor de arquivo ou algum outro recurso gerenciado pelo sistema operacional, que a JVM não saberá desalocar automaticamente como parte da GC. É possível ter um leak do recurso, seja temporário ou permanente, mesmo para objetos que foram coletados por GC.
Além disso, é comum que surjam novos tipos de problemas que são efeito colateral da nova tecnologia, como:
• Pausas de GC: como o coletor trabalha “em batch”, embora o custo total por objeto seja bem menor que na opção de memória manual, quando esse custo é concentrado por que milhares ou milhões de objetos são liberados de uma só vez, isso pode ser um problema;
• Problemas misteriosos envolvendo tuning e ajustes de GC: por exemplo, é possível sofrer uma OutOfMemoryException quando existe muito mais memória livre que o exigido por uma solicitação de alocação. E entre problemas menos explícitos, pode-se ter perdas importantes de desempenho devido à simples falta dos parâmetros ideais para tunar a VM;
• Consumo de memória além do necessário: também há cenários em que isso piora com GC. Para objetos de ciclo de vida simples (caso oposto ao anterior), o gerenciamento manual de memória permite deletar o objeto imediatamente após seu último uso, evitando a retenção de memória por um único nanossegundo. Já com GC, é preciso esperar pela próxima coleta;
• Retenção de recursos além do necessário: a aplicação pode desalocar corretamente o recurso, mas só muito tempo após seu último uso. Isso tem sintomas não graves mas desagradáveis, por exemplo um arquivo pode permanecer bloqueado para escrita por muito tempo ao invés de ser desbloqueado imediatamente após a aplicação tê-lo utilizado, e uma conexão que já foi utilizada pode permanecer indisponível para outras transações que precisam de conexões de um pool de tamanho limitado.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado
Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
Gerenciando Memória e Recursos
Você acha que devido ao GC, não precisa se preocupar com alocação de memória e outros recursos? Achou errado
Conheça as melhores práticas – e as piores – para administrar recursos, prevenir leaks e outros erros
De que se trata o artigo:
Examinamos os problemas de gerenciamento de memória e de recursos em Java, investigando várias “receitas” de bugs como leaks de memória ou retenção indevida de recursos, e aprendendo a evitar estes problemas.
Para que serve:
O gerenciamento correto e eficiente de memória e recursos é uma necessidade de qualquer aplicação, especialmente aquelas destinadas a executar continuamente durante muito tempo, ou aquelas que devem enfrentar picos de atividade intensa e apresentar boa escalabilidade. Leaks de memória podem resultar em problemas que vão desde mau desempenho até crashes da VM com OutOfMemoryError. Ineficiência no gerenciamento de recursos podem causar problemas difíceis de diagnosticar, como a observação que uma aplicação não consegue escalar acima de uma taxa modesta de transações simultâneas mesmo com o servidor aparentemente pouco carregado.
Em que situação o tema é útil:
Bugs relacionados à alocação de memória e manipulação de recursos são inaceitáveis em sistemas de “missão crítica”, mas devem ser evitados em qualquer tipo de aplicação. Uma das dificuldades de combater tais bugs, especialmente os de gerenciamento de memória, é que devido ao recurso de GC do Java, muitos desenvolvedores dão pouca atenção ao problema, achando que a JVM irá magicamente dar conta do recado. Infelizmente não é tão simples assim; neste artigo, exploramos alguns anti-patterns que com freqüência resultam em leaks de memória e outros problemas.
Na evolução das linguagens de programação, grandes avanços como a técnica de GC (Garbage Collection) são geralmente interpretados como “o fim de todos os seus problemas”, pelo menos de uma ampla categoria como os problemas relacionados ao gerenciamento de memória. Mas no longo prazo essa esperança sempre acaba em decepção, pelo menos parcial, pois nem todos os problemas atacados pela nova tecnologia terminam totalmente. Vamos fazer uma rápida análise dos efeitos da GC, em comparação com linguagens com gerenciamento manual de memória como C/C++:
• Corrupção do heap: totalmente eliminado (devido parcialmente à GC, e parcialmente a outras características de linguagens gerenciadas);
• Leaks de memória: mais raros, mas não eliminados;
• Consumo de memória além do necessário: pouco melhorado. A melhoria vem da programação mais simples, especialmente para objetos com ciclo de vida complexo (referenciados de muitos lugares, alocados e liberados em lugares e momentos distantes). A GC permite a cada parte do código liberar referências para objetos utilizados tão logo estes deixem de ser localmente úteis, e quando não houver mais nenhuma referência, a VM detecta isso e remove o objeto. Já em programas com memória manual, quando é complicado determinar quando um objeto pode ser deletado, isso quase sempre resulta numa retenção muito conservadora do objeto, que só é deletado muito depois do último momento em que foi realmente usado;
• Leaks de recursos: “recursos” são objetos que exigem procedimentos especiais de desalocação, por exemplo a liberação de um socket, conexão de pool, descritor de arquivo ou algum outro recurso gerenciado pelo sistema operacional, que a JVM não saberá desalocar automaticamente como parte da GC. É possível ter um leak do recurso, seja temporário ou permanente, mesmo para objetos que foram coletados por GC.
Além disso, é comum que surjam novos tipos de problemas que são efeito colateral da nova tecnologia, como:
• Pausas de GC: como o coletor trabalha “em batch”, embora o custo total por objeto seja bem menor que na opção de memória manual, quando esse custo é concentrado por que milhares ou milhões de objetos são liberados de uma só vez, isso pode ser um problema;
• Problemas misteriosos envolvendo tuning e ajustes de GC: por exemplo, é possível sofrer uma OutOfMemoryException quando existe muito mais memória livre que o exigido por uma solicitação de alocação. E entre problemas menos explícitos, pode-se ter perdas importantes de desempenho devido à simples falta dos parâmetros ideais para tunar a VM;
• Consumo de memória além do necessário: também há cenários em que isso piora com GC. Para objetos de ciclo de vida simples (caso oposto ao anterior), o gerenciamento manual de memória permite deletar o objeto imediatamente após seu último uso, evitando a retenção de memória por um único nanossegundo. Já com GC, é preciso esperar pela próxima coleta;
• Retenção de recursos além do necessário: a aplicação pode desalocar corretamente o recurso, mas só muito tempo após seu último uso. Isso tem sintomas não graves mas desagradáveis, por exemplo um arquivo pode permanecer bloqueado para escrita por muito tempo ao invés de ser desbloqueado imediatamente após a aplicação tê-lo utilizado, e uma conexão que já foi utilizada pode permanecer indisponível para outras transações que precisam de conexões de um pool de tamanho limitado.
ATENÇÃO! A exibição deste artigo foi interrompida.
#Este é um post fechado Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!
2 COMENTÁRIOS
Mauricio Dos Santos Magnani Junior
em 20/12/2009 20:00 - Responder
Muito bom... Excelente artigo !
Esse é o melhor autor da devmedia...
Esse é o melhor autor da devmedia...
em 20/12/2009 20:00 - Responder
Leandro Lamanna Zanardi
em 1/1/2010 12:23 - Responder
Excelente artigo e este é um conhecimento obrigatório de todos desenvolvedores. Devido ao incorreto uso da linguagem por muitos, inclusive pela Sun como citado pelo autor, ouvimos da maioria dos desenvolvedores do extremo baixo nível como C que java é lento, consome memória e não pode ser utilizado para games por exemplo, o que é um grande engano. Sou arquiteto de games para web e desktop e uma das minhas linguagens favoritas para tal é o java.
Desenvolver em java é muito simples e muito comum, o complexo é desenvolver corretamente, sem o uso excessivo de apis e frameworks obscuros.
Infelizmente este conhecimento está cada vez menos difundido e temos cada vez menos desenvolvedores java e mais usadores de framework que não conhecem a arquitetura dos mesmos.
Parabéns ao autor e a java magazine.
Desenvolver em java é muito simples e muito comum, o complexo é desenvolver corretamente, sem o uso excessivo de apis e frameworks obscuros.
Infelizmente este conhecimento está cada vez menos difundido e temos cada vez menos desenvolvedores java e mais usadores de framework que não conhecem a arquitetura dos mesmos.
Parabéns ao autor e a java magazine.
em 1/1/2010 12:23 - Responder
Você está em:
canal Java
Publicidade
Estudo comparativo entre banco de dados IBM Informix e Microsoft SQL
Osvaldo Pinali Doederlein
Space do autor
é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.
Space do autor
0
0
Conheça os planos de créditos DevMedia e visualize esse post agora mesmo!