Oi,
Tenho uma aplicação Swing que adora dar Java Heap Space (OutOfMemory).
Estava tentando instalar o plugin Profiler do Eclipse para tentar encontrar quais variáveis ou métodos ou objetos estão presos na “memoria”. Porém foi impossível instalar esse plugin.
Existe alguma forma (Alguma classe da api) que me disponibiliza essas informações? Mostrando em Sysout quais os objetos estão no mundo matrix?
Tchauzin!
Dê uma olhada no Visual VM. Ele acompanha o próprio JDK 6. Fica na pasta bin do JDK.
É muito fácil, basta entrar nele e se conectar a uma aplicação que já esteja rodando.
Oi,
Que bom!
Vou testa-la exatamente agora.
Obrigada Vini.
Tchauzin!
Oi,
Meio confuso!
Estou clicando em HeadDump -> Classes:
int[] Instances: 3064 (8,6%) Size: 3072008 (67%)
byte[] instances: 1682 (4,7%) Size: 280180 (6,1%)
Isso que dizer que 67% está sendo ocpuado por instanciar int[] ?
Tchuzin!
[quote=lina]Oi,
Meio confuso!
Estou clicando em HeadDump -> Classes:
int[] Instances: 3064 (8,6%) Size: 3072008 (67%)
byte[] instances: 1682 (4,7%) Size: 280180 (6,1%)
Isso que dizer que 67% está sendo ocpuado por instanciar int[] ?
[/quote]
Exatamente (arrays são objectos). Repare que o profiler não destingue entre classes “suas” e de frameworks e da jse. Esses arrays podem estar em muitos lugares diferentes.
Se não me engano existe uma opção para filtrar por pacote, ai vc pode ver apenas as classes da sua aplicação, contudo, nem sempre o memory leak acontece nas nossas classes, normalmente acontece em classes de frameworks intermédios.
O que voce esta carregando que usa int[]?
Se for arquivos voce pode usar a classe FileChannels pra melhorar isso.
Uma boa é você procurar qual das suas classes de negócio está ocupando mais espaço. Bom, analise o heap e veja a arvore de alocação de cada instância, por amostragem (existe uma opção de mostrar as instancias aí). Muito provavelmente esses ints pertencerão a mesma classe. Tente por isso rastrear qual classe de negócios do seu programa tem o potencial problema.
[quote=lina]Oi,
Meio confuso!
Estou clicando em HeadDump -> Classes:
int[] Instances: 3064 (8,6%) Size: 3072008 (67%)
byte[] instances: 1682 (4,7%) Size: 280180 (6,1%)
Isso que dizer que 67% está sendo ocpuado por instanciar int[] ?
Tchuzin![/quote]
Oi lina,
Precisa prestar atenção quantidade de recursos alocados pelo tempo. Vetores de inteiro e vetores de byte podem significar vários tipos de objetos, como imagens, buffers, etc…
Presta atenção no int[], que pode ser um ArrayList, que está sendo incrementado e não há uma instrução para limitar sua capacidade.
algo do tipo:
[code]List lista = new ArrayList(X);
lista.add(obj); // é incrementado, mas posteriormente não existe um método que checa seu limite [/code]
é um memory leak, difícil de ser detectado, porque java vm gerencia e aloca memoria dinamicamente para ele(até extender os limites do heap da sua aplicação).
Oi,
Estou notando que está meio lento a parte em que preciso adicionar no ArrayList
os dados da coluna para dar update.
Então utilizo um for percorrendo todas as colunas da minha tabela:
[code]int
ln_coluna = lo_rs_tabela_origem.getMetaData().getColumnCount();
for (int ln = 1; ln <= ln_coluna; ln++) {
}[/code]
Dentro deste for, estou utilizando switch para verificar de qual tipo é a coluna:
switch (lo_rs_tabela_origem.getMetaData().getColumnType(ln))e os case estão assim:
[code]case Types.BLOB:
Blob
lo_blob_origem = lo_rs_tabela_origem.getBlob(ln);
// Adiciona no ArrayList
lo_al_columns.add
(
lo_blob_origem == null
? null
: lo_blob_origem.getBytes(new Long(1), new Long(lo_blob_origem.length()).intValue())
);
break;
case Types.CLOB:
Clob
lo_clob_origem = lo_rs_tabela_origem.getClob(ln);
lo_al_columns.add
(
lo_clob_origem == null
? null
: lo_clob_origem.getSubString(new Long(1).longValue(), new Long(lo_clob_origem.length()).intValue()).toCharArray()
);
break;
case Types.TIMESTAMP:
case Types.DATE:
lo_al_columns.add(lo_rs_tabela_origem.getTimestamp(ln));
break;[/code]
…
Tchauzin!
[quote=lina]Oi,
Estou notando que está meio lento a parte em que preciso adicionar no ArrayList
os dados da coluna para dar update.
Então utilizo um for percorrendo todas as colunas da minha tabela:
[code]int
ln_coluna = lo_rs_tabela_origem.getMetaData().getColumnCount();
for (int ln = 1; ln <= ln_coluna; ln++) {
}[/code]
Dentro deste for, estou utilizando switch para verificar de qual tipo é a coluna:
switch (lo_rs_tabela_origem.getMetaData().getColumnType(ln))e os case estão assim:
[code]case Types.BLOB:
Blob
lo_blob_origem = lo_rs_tabela_origem.getBlob(ln);
// Adiciona no ArrayList
lo_al_columns.add
(
lo_blob_origem == null
? null
: lo_blob_origem.getBytes(new Long(1), new Long(lo_blob_origem.length()).intValue())
);
break;
case Types.CLOB:
Clob
lo_clob_origem = lo_rs_tabela_origem.getClob(ln);
lo_al_columns.add
(
lo_clob_origem == null
? null
: lo_clob_origem.getSubString(new Long(1).longValue(), new Long(lo_clob_origem.length()).intValue()).toCharArray()
);
break;
case Types.TIMESTAMP:
case Types.DATE:
lo_al_columns.add(lo_rs_tabela_origem.getTimestamp(ln));
break;[/code]
…
Tchauzin!
[/quote]
checa se essa lista( lo_al_columns) não está crescendo durante o tempo de execução da aplicação.
Oi,
Isso ele não está… Eu instancio o Array passando a quantidade de colunas.
Depois na próxima coluna eu limpo e crio ele novamente.
Coloquei um System.gc no final de todo o processo… parece que isso resolveu bastante a situação.
Obrigada!
Tchauzin!
[quote=lina]Oi,
Estou notando que está meio lento a parte em que preciso adicionar no ArrayList
os dados da coluna para dar update.
Então utilizo um for percorrendo todas as colunas da minha tabela:
[code]int
ln_coluna = lo_rs_tabela_origem.getMetaData().getColumnCount();
for (int ln = 1; ln <= ln_coluna; ln++) {
}[/code]
Dentro deste for, estou utilizando switch para verificar de qual tipo é a coluna:
switch (lo_rs_tabela_origem.getMetaData().getColumnType(ln))e os case estão assim:
[/quote]
A lentidão pode ser derivada de estar lendo os metadados várias vezes. Tente executar getMetaData apenas uma vez. se necessário passe o objeto para submetodos. Sempre que vc chama isso ha comunicação com o banco e isso é uma fator de lentidão maior que a jvm. Contudo, não daria outofmemory (em tese)
[quote=lina]Oi,
Isso ele não está… Eu instancio o Array passando a quantidade de colunas.
Depois na próxima coluna eu limpo e crio ele novamente.
Coloquei um System.gc no final de todo o processo… parece que isso resolveu bastante a situação.
Obrigada!
Tchauzin![/quote]
O System.gc funciona relativamente. Se existir objetos referenciados, ele não funciona. Mas se a lista foi limpa, então não é essa ae o foco do problema.
Oi,
Encontrei o problema!
Cada vez que replicava uma base de dados meu replicador criava uma nova conexão.
Sendo assim, quando estava em modo automático (Cada 5 segundos replicava novamente) e tinha apenas um banco de origem e um banco de destino, o replicador criava +1 conexão não fechando a outra.
Precisei executar o método DisconnectAll() para fechar as conexões e abrir novamente a cada replicação feita. Isso consumia muito Heap!
O programa ajudou muito e vocês também!
Obrigado a todos!
Tchauzin!
[quote=lina]Oi,
Encontrei o problema!
Cada vez que replicava uma base de dados meu replicador criava uma nova conexão.
Sendo assim, quando estava em modo automático (Cada 5 segundos replicava novamente) e tinha apenas um banco de origem e um banco de destino, o replicador criava +1 conexão não fechando a outra.
Precisei executar o método DisconnectAll() para fechar as conexões e abrir novamente a cada replicação feita. Isso consumia muito Heap!
O programa ajudou muito e vocês também!
Obrigado a todos!
Tchauzin![/quote]
Comsumir muito heap até pode, o que não pode é ficar alocado. Legal que deu certo, leaks são cansativos e difíceis de encontrar.
Se estiver rodando a aplicação na HostSpot (VM da Sun) (não me recordo das outras, mas também devem possuir), rode com a opção
Isso gera um arquivo com o dump do HeapSpace no caso da VM morrer por OutOfMemory.
At.
[quote=lina]Oi,
Isso ele não está… Eu instancio o Array passando a quantidade de colunas.
Depois na próxima coluna eu limpo e crio ele novamente.
Coloquei um System.gc no final de todo o processo… parece que isso resolveu bastante a situação.
Obrigada!
Tchauzin![/quote]
Algo que pode te ajudar um pouco no gerenciamento da memória disponível pode ser encontrado em um capítulo disponível para download do livro Arquitetura Java (disponibilizado pela Caelum). Dentre outras coisas, la menciona algunas alternativas ao algoritmo de coleta implementado nas VM´s.
O link: http://www.arquiteturajava.com.br/livro/gerenciamento-de-memoria-e-garbage-collector.pdf
At.