2010-09-30 7 views
0

J'utilise un webservice sur apache tomcat 6.0.29 avec sun jdk1.6.0_21, le webservice utilise spring, hibernate, axe 1.4, apache cxf, jaxb et quelques autres bibliothèques.Nombre de classes chargées

Je surveille l'instance de tomcat avec javamelody, et je peux reconnaître une croissance constante des classes chargées et la quantité de classes chargées continue de croître pendant le temps en ligne.

Donc, y a-t-il un moyen de trouver quelles classes sont produites, ne devrait pas le garbage collector faire un nettoyage.

Ce sont mes JAVA_OPTS

-Xmx768m -Xms512m -Xss4m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=128m -XX:PermSize=128m 
+2

* "(<100k et toujours en croissance)" * Alors ... deux? * canards et courses * ;-) –

+0

TJ - en fait un commentaire très pertinent. <100k et en croissance est la pire description que j'ai entendu depuis un moment ... –

Répondre

1

Vous parlez de chargés cours ou chargées instances.

Presque 100k classes est beaucoup. La RT entière de JRE 1.6 a environ 17k classes, y compris les classes internes. 100k instances n'est pas vraiment tout ça.

De plus, les classes ne sont pas déchargées (à l'exclusion des frameworks conçus pour ce faire, comme les modules OSGi). Les instances sont cependant collectées lorsque nécessaire.

Si vous n'avez pas d'exceptions OutOfMemory (vous avez beaucoup d'espace), le garbage collector n'a pas besoin d'être très agressif. Démarrez tomcat avec moins de mémoire et vous verrez que le gc va commencer à collecter plus agressivement. Je ne recommande pas de faire cela sur la production car diminuera les performances en exerçant une pression sur le CPG. En outre, un outil comme YourKit peut vous en dire beaucoup sur les objets en mémoire, y compris je crois que combien sont éligibles pour GC. Ce qui ne veut pas dire que le gc doit les collecter, mais cela peut le faire.

0

Une classe peut seulement être déchargée après que son chargeur de classe ait été récupéré. Vous voudrez peut-être faire un vidage de tas et découvrir quelles références les classloaders.

Pour savoir comment analyser les décharges de tas, voir: General strategy to resolve Java memory leak?