char[] e byte[] ocupando 130MB de memória

Olá pessoal,

tenho uma aplicação que publicada está quebrando a todo momento com permgen space.

Executei o profiler do Netbeans e testo as funcionalidades da minha aplicação. Depois de um tempo, as classes char[] e byte[] juntas ocupam algo em torno de 130MB. Isso é normal?? Já verifiquei o código e não consigo achar locais onde pode haver alguma estrutura de iteração infinita ou algo do tipo, mas estou acumulando esses 130MB com somente 1 usuário logado. Imagina o publicado com mais usuários.

Sim, essas classes são fundações para as Strings. E as strings são usadas em diversas outras (resultsets, strings, stringbuilders, labels, etc).
Não adianta olhar para tipos de dados primitivos, você deve procurar onde estão sendo usados, e quem está criando tantos strings assim.

Faz sentido o que vc disse, delas serem resultados de resultsets e stringbuilders pois utilizo muito builders. Porém imaginei que o coletor de lixo as removesse da memória no momento em que não são mais referenciadas. Não??

adrianostanley wrote:Faz sentido o que vc disse, delas serem resultados de resultsets e stringbuilders pois utilizo muito builders. Porém imaginei que o coletor de lixo as removesse da memória no momento em que não são mais referenciadas. Não??

Removem sim. Se estão aí, é porque estão sendo referenciadas, o trabalho é só descobrir por quem.
Mas é bom rodar o garbage collector, comparar dados, ver se isso está crescendo ou se mantendo, etc.

Entendi.

Aproveitando, sem querer abusar, você sabe se isso pode estar acontecendo por um mal gerenciamento das sessões do Hibernate?

Reparei que esse número sempre cresce quando há alguma consulta no banco. Eu sempre fecho as sessões mas pode ser que elas continuem sendo referenciadas pelo SessionFactory ou ele já cuida disso?

This message was edited 1 time. Last update was at 10/09/2011 17:37:58

Deveria cuidar.

Uma forma de observar isso fácil e eficiente é fazer uma amostragem sobre as instâncias de chars/bytes alocadas, que objetos as contém.
Vá rastreando a pilha toda, que vc acaba chegando no culpado. Faça isso para umas 10 ou 15 instâncias, e veja se é sempre o mesmo.

Outra coisa, há muitas classes aí associadas a XML, ao jasper e a reflexão.
Esse é um sinal de que pode estar por aí o culpado também.

Tome muito cuidado se sua aplicação tem variáveis estáticas. Elas geralmente seguram todo mundo para quem apontam na memória. Como nunca saem de escopo, elas acabam se tornando vilãs no gerenciamento de memória.

Análise de memória é geralmente mais complicada do que análise de performance. É necessário estudar bem a base, para tentar entender quem está alocando o que, e quem está segurando quem.
Não é tão trivial quanto só olhar para um gráfico e dizer quem é o culpado (como fazemos com performance), infelizmente.

Tá certo!!! Cara, mt obrigado pela ajuda!!! Valeu muito!!

Depois de analisar bastante o código, gerei um Profiler das classes do Hibernate.

Imagino que a classe Alias seja um dos problemas, pois quem as utiliza é o Criteria. Criteria é convertido em String que é enviada ao banco. Um String é um char[], certo?

Será que o problema pode estar aí?

Outra dúvida, o Profiler do Netbeans, quando indica "Bytes alocados", quer dizer que esses bytes estão alocados exatamente nesse momento ou isso é informação de histórico, isto é, se eu estou vendo a classe no Profiler, significa que ela está ainda alocada pela aplicação??

Notícias, artigos e o maior fórum brasileiro sobre Java