Consumo de memoria muito alto

Você ja experimentou comentar esse código e gerar um novo jar e rodar para ver o que acontece?

eu jah fiz isso hushuas…
mas diminuiu um pouco soh…

eu tenho tmbm umas 3 tabelas no sistema q tem um TableCellRenderer nelas…onde o codigo edita cada coluna ta tabela…ele faz uma verificação para ver qual cor ele ira pintar o fundo de cada linha…

pode ser isso tmbm ? rs

Isso pode causar o problema, tb, no java eu nunca mechi com thread, mas quando eu trabalhava com delphi tinha um negocio que eu coloca a prioridade na thread, concerteza deve ter isso no java tb, da uma olhada e coloca a prioridade dela baixa, ai ele aloca um pouco menos de memória pra esse processo, blz? Se nao achar isso fala ai que a gente da outro jeito…rsrsr

Bom, é necessário realmente ter 2 threads que se comunicam com o banco? Se sim, então tenta setar baixa prioridade a elas

Thread t = new Thread(); t.setPriority(Thread.MIN_PRIORITY);

sim eh necessario rsrs…
vou tentar essa opção da prioridade…
obrigado pelas sugestoes! hehe

eu testei aqui mas diminuiu muito pouco rsrs…

eu acredito q o problema seja no TableCellRenderer mesmo…

Porque a tabela que contem ele possui muitos registros (hoje está com 3000…aumenta uns 20 por dia)

mas quanto a isso tem alguma solução?

-Xms30m -Xmx50m

Coloca isso na launch da sua aplicação.
Maiores detalhes em: http://www.vivaolinux.com.br/dica/Melhorando-a-performance-de-sua-Java-Virtual-Machine/

Roda a aplicação em modo profile. Talvés lá você consegue alguma informação.

Cara tenta descobrir em qual momento que ela começa a consumir tanta memoria, tb as vezes o programa vai usar esse tanto de memória mesmo! :shock: rsrsr, coisas que ficam mudando a tela, costuma consumir muita memória mesmo…

eh obrigatorio por a quantidade minima (Xms) e maxima (Xmx)?!
nao pode por somente a maxima!?

entao…eu faço isso…mas ele consome praticamente a mesma coisa em todas as tarefas do sistema…
mas o qe eu percebi eh q depois de bastante tempo q ele ta rodando q o consumo aumenta…
pq eu fecho ele (mas ele cai na barra de tarefas com um trayIcon) e decho ele la…
depois de um tempo eu olho quanto ta o consumo e ta um absurdo rsrs…isso sem fazer nada…
isso q eh estranho :S

Cara, puts eu ja tive uma vez um problema desse de memoria, é complexo… Vc realmente precisa dessa tabela ? Não tem como contornar isso nao?

Olha só , nas suas consultas a banco de dados … você está dando close em todos os recursos?

Usa hibernate ou JDBC?

No caso de JDBC, close nos Resultsets , Statements e Connections
No caso de Hibernate, session.close();

ah , close nesta ordem.
Resultsets primeiro, statements e então connections …
e tem que colocar os closes no finally do try/catch

Resultset rs = null;

Statement stmt = null;

Connection conn = null;

try {

rs = …

stmt = …

conn = …

…

} catch (exceptions… ) {

…

} finally {

try {

if (rs != null) rs.close();

if (stmt != null) stmt.close();

if (conn != null) conn.close();

} catch (SQLException e) { throw new RuntimeException (e) }

}

minha aposta ta nisso

na verdade eu abro a conexão junto com o programa e soh fecho quando o programa fecha…

ResultSet, Statement e Connection ficam abertos o tempo todo?

eh o seguinte…eu peguei esse projeto pela metade…entao uma parte outra pessoa fez…e pelo q eu estou vendo aqui a unica coisa q eh feita eh abrir uma conexão no inicio do programa (getConnection()) e no fim ela eh fechada (close())…
quando sao feitas as consultas nenhum result set eh fechado…
eu estou fazndo isso como padrao pois ja estava assim achei melhor nao modificar…

mas qual seria a melhor forma entao?!

Bom, uma boa prática é colocar transações em um bloco try-catch-finally e fechar as conexões dentro do finally.

Você tem que fechar os resultsets e statements … da uma olhada na minha segunda resposta desta discussão. Tem um exemplo lá. Tem que colocar no finally.

Tá causando leak de memória e vai só enchendo a heap … por isso teu software deve ta consumindo muita memória.

As melhores práticas são:

1. Sempre fechar statements, connections e resultsets em um finally. Outros recursos como arquivos, sockets e streams também devem ser fechados num finally.
2. Como conexões são caras de serem criadas, use um pool de conexões como o Jakarta DBCP ou c3p0.
3. Sempre que tiver um problema de memória ou performance, certifique-se do problema através de um profiler. Ótimas opções são o Visual VM ou o profiler do Netbeans.

ahhh…belzaaa…
vo concerta os metodos entao
tem muito hsuahsuah

brigado pela ajuda
VLWW!

Aproveita o feriado para o refactoring Bom feriado para você …

hsuahsuahaus…
vlww…
pra vcs ae tmbm!

Schoker:

eh obrigatorio por a quantidade minima (Xms) e maxima (Xmx)?!
nao pode por somente a maxima!?

Se você colocar isso você vai estourar o heap. Não tem como fazer uma aplicação consumir menos só porque você limitou o software a alocar menos ou mais.
Use a jvisualvm para ver qual tipo de dado está usando mais espaço e reveja o código.