constantPoolClass en Java Heap?

Question

He heredado un applet de Java (un < APPLET real >) que arroja una excepción OutOfMemory después de aproximadamente 4 días de tiempo de ejecución. La naturaleza del applet es tal que la gente realmente lo dejará abierto durante largos períodos de tiempo.

Después de casi dos días seguidos, -histo jmap muestra los consumidores montón superiores como:

 
    num #instances #bytes class name 
    --- ---------- ------ ---------- 
     1:  14277 7321880 <constantPoolKlass> 
     2:  59626 5699968 <constMethodKlass> 
     3:  14047 5479424 <constantPoolCacheKlass> 
     4:  14277 5229744 <instanceKlassKlass> 
     5:  59626 4778944 <methodKlass> 
     6:  71026 3147624 <symbolKlass> 

El problema es que no entiendo lo que cualquiera de estas cosas son. Hay al menos dos cosas sucediendo: constantPoolKlass + constantPoolCacheKlass + instanceKlassKlass aparecen relacionadas, al igual que constMethodKlass + methodKlass. A partir de los nombres, aparecen relacionados con un cargador de clases.

Si tuviera que adivinar diría que el applet ha creado aproximadamente 14,277 objetos donde cada objeto tiene aproximadamente 4 métodos, para aproximadamente 59626 métodos en total. Sin embargo, el resultado de jmap no muestra ninguna clase con un número tan grande de instancias, ni parece que la suma total de otros objetos de clase sume 14277. Así que tal vez soy incorrecto sobre lo que hacen estos objetos. ¿Alguien puede explicar?

Answer 1

Sí, parece que tiene fugas de cargadores de clase. Si no está realmente creando cargadores de clases en su propio código (generalmente a través de URLClassLoader.newInstance o XSLT), puede estar relacionado con la recarga del applet (aunque normalmente obtendrá el mismo cargador de clases). Las posibles causas de fugas son ThreadLocal, los controladores JDBC y java.beans.

Answer 2

Spot on - obviamente un problema de ClassLoader. Es muy extraño ver eso en un applet; normalmente solo es un problema con los servidores de aplicaciones o IDEs.

2 maneras de depurar este: o bien conseguir un generador de perfiles reales montón que puede mostrar donde se hace referencia a los datos de la clase fuera de control, o el parche las clases de API como se describe aquí: http://www.onjava.com/pub/a/onjava/2004/06/30/classloader2.html?page=2