Memory Leak - O que o CG está limpando?

• Use um profiler - por exemplo, o Eclipse e o NetBeans têm um.
• Se você não puder usar o profiler por algum motivo mas está usando Java 5.0 (no Solaris ou Linux) ou Java 6.0 (Solaris, Windows, Linux) você pode usar jmap e jhat para checar quais são as classes e objetos que estão presentes em um determinado momento.

É por ai mesmo.

Estou usando o jmap e o jhat.

O que eu queria saber é: “O que o GC está limpando a todo momento !!!???”

Eu vejo que ele entra direto limpando as coisas, mas o que eu não sei.

Aqui a regra é clara. GC não pode entrar nunca!

Sergio

saoj:

É por ai mesmo.

Estou usando o jmap e o jhat.

O que eu queria saber é: “O que o GC está limpando a todo momento !!!???”

Eu vejo que ele entra direto limpando as coisas, mas o que eu não sei.

Aqui a regra é clara. GC não pode entrar nunca!

Sergio

tem acesso ao fonte ? caso voce tenha desconfianca de alguma coisa… implemente o metodo finalize do objeto e mande ele printar o q esta morrendo…

GC entrar nunca eu acho impossivel… afinal ele tem q limpar a EDEN , o que voce precisa observar eh quanto tempo ele gasta…

as vezes sao milesimos de segundos… caso voce precise que nao entre tão cedo… voce vai necessitar que uma super heap… com uma super EDEN… o que vai lhe custar muita ram… e nao eh garantia de “nao entrada”

Boa dica, mas pode ser qualquer objeto! O código tem mais de 1000 linhas e muitas classes!

Por isso q disse… voce tem que desconfiar de alguma coisa… algum processo que esteja colocando esse ML…

as vezes é uma boa pratica botar esses metodos em todas as classes para fazer este debug (porem retire eles depois… pois vai degradar a performance e causar uma demora maior na retirada da memoria da heap )

Mas e se for STRING ???

Bem… se for string… de que adianta saber que um monte de string esta limpando ? voce nao desconfia de nenhum LUGAR no codigo que possa estar causando o leak ?o negocio eh usar um profiler para saber a quantidade de objetos de cada tipo estao na memoria… e se estao diminuindo…
mas repito… o que importa nao eh quantas vezes os GC entra em acao… e sim o tempo que ele come…

Voce poderia printar aqui os tempos do GC ?

O meu caso é particular. Não há memory leak, a memória está sendo limpada pelo GC normalmente e rapidamente. O problema é que o GC está entrando umas 5 vezes por segundo, ou seja, algo está’ criando objeto sem necessidade.

O problema é que aqui cada millisegundo conta.

Alguém já viu esse tal de -Xverbosegc ???

Acho que isso que eu preciso só que o meu java 1.5.0_09 não possui essa opçao.

C:\java\hat_test&gtjava -X

-Xmixed           mixed mode execution (default)

-Xint             interpreted mode execution only

-Xbootclasspath:<directories and zip/jar files separated by ;>

set search path for bootstrap classes and resources

-Xbootclasspath/a:<directories and zip/jar files separated by ;>

append to end of bootstrap class path

-Xbootclasspath/p:<directories and zip/jar files separated by ;>

prepend in front of bootstrap class path

-Xnoclassgc       disable class garbage collection

-Xincgc           enable incremental garbage collection

-Xloggc:<file>    log GC status to a file with time stamps

-Xbatch           disable background compilation

-Xms<size>        set initial Java heap size

-Xmx<size>        set maximum Java heap size

-Xss<size>        set java thread stack size

-Xprof            output cpu profiling data

-Xfuture          enable strictest checks, anticipating future default

-Xrs              reduce use of OS signals by Java/VM (see documentation)

-Xcheck:jni       perform additional checks for JNI functions

-Xshare:off       do not attempt to use shared class data

-Xshare:auto      use shared class data if possible (default)

-Xshare:on        require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.

Alguem com java 1.4 poderia digitar java -X para saber se essa opçao está lá ?

Você pode usar “-verbose:gc” (não tem o X) ou então “-XX:+PrintGC” (acho que é equivalente, mas não tenho certeza)

Os dois funcionaram mas são equivalentes ao loggc, ou seja, só logam tempo!

Eu preciso saber o que eles estão limpando!

nao querendo ser chato… mas acho q isso não vai ser possivel… o trace deste nivel vai ser BEM confuso…

no meu caso… meu GC só ficava louco quando minha HEAP estava muito pequena… entao precisava ser limpa todo o tempo

Entao ta na hora de usar um profiler de verdade

Descola uma licenca do JProfiler.