constantPoolClass dans Java tas?

Question

J'ai hérité d'une applet Java (<APPLET>) qui déclenche une exception OutOfMemory après environ 4 jours d'exécution. La nature de l'applet est telle que les gens la laisseront ouverte pendant de longues périodes de temps.

Après presque deux jours de course, jmap -histo montre les plus grands consommateurs de tas comme:

 
    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> 

Le problème est, je ne comprends pas ce que l'une de ces choses. Il y a au moins deux choses qui se passent: constantPoolKlass + constantPoolCacheKlass + instanceKlassKlass apparaissent liés, tout comme constMethodKlass + methodKlass. À partir des noms, ils apparaissent liés à un chargeur de classe.

Si je devais deviner je dirais que l'applet a créé environ 14 277 objets où chaque objet a environ 4 méthodes, pour environ 59626 méthodes au total. Pourtant, la sortie de jmap ne montre aucune classe avec un si grand nombre d'instances, ni ne ressemble à la somme totale des autres objets de classe ajouter jusqu'à 14277. Donc peut-être que je suis incorrect sur ce que font ces objets. Quelqu'un peut-il expliquer?

Answer 1

Yup, on dirait que vous avez des fuites sur les chargeurs de classe. Si vous ne créez pas réellement des chargeurs de classes dans votre propre code (généralement via URLClassLoader.newInstance ou XSLT), cela peut être lié au rechargement de l'applet (bien que vous récupériez généralement le même chargeur de classe). Les causes possibles des fuites sont ThreadLocal, les pilotes JDBC et java.beans.

Answer 2

Spot sur - évidemment un problème de ClassLoader. Très étrange de voir cela dans une applet cependant; normalement, c'est seulement un problème avec les serveurs d'applications ou les IDE.

2 façons de déboguer: soit obtenir un vrai profileur tas qui peut vous montrer où vos données de classe d'emballement est référencé, ou patcher les classes de l'API comme décrit ici: http://www.onjava.com/pub/a/onjava/2004/06/30/classloader2.html?page=2