Existe-t-il un moyen d'éviter les fuites de mémoire liées au non-déploiement dans Tomcat?

Question

Cette question est pour tous ceux qui ont déjà testé le "Trouver les fuites" dans le Tomcat manager et a obtenu quelques résultats comme ceci:

Suivant les applications web ont été arrêtés (reloaded, non déployée), mais leurs classes de cycles précédents sont toujours chargés en mémoire, ce qui entraîne une fuite de mémoire (utiliser un profiler à confirmer):
/qui fuit-app-name

Je suppose que cela a quelque chose à voir avec le "Perm Gen espace" erreur vous obtenez souvent avec de fréquentes redéploiements.

Donc, ce que je vois dans la jconsole lorsque je déploie mes classes chargées, va d'environ 2k 5k. Alors, vous pensez qu'un undeployment doivent les déposer à l'arrière en bas à 2k, mais ils restent à 5k.

J'ai aussi essayé d'utiliser la JVM suivant les options:

-XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled

Je ne vois TRÈS mineur creux dans le montant de Perm Gen espace utilisé, mais pas ce que j'attendais et le chargé le nombre de classes n'a pas diminué.

Donc, il y a un moyen de configurer Tomcat ou la conception de votre application pour décharger mieux sur un undeployment? Ou sommes-nous coincés avec de redémarrer le serveur après certaines grandes sessions de débogage?

Tomcat version de sortie:

Version du serveur: Apache Tomcat/6.0.29
Serveur de construction: 19 juillet 2010 1458
Numéro de serveur: 6.0.0.29
Nom du système d'exploitation: Windows 7
OS Version: 6.1
Architecture: x86
JVM Version: 1.6.0_18-b07
JVM Vendeur: Sun Microsystems, Inc.

Mise à jour:

Grâce à celias réponse, j'ai décidé de faire un peu plus creuser et je pense que j'ai déterminé le coupable d'être dans mon application grâce à CXF, le Printemps et l'JAXB.

Après j'ai appris comment le profil d'une application Java, j'ai fait le profiler à Tomcat et pris quelques tas de détritus et les instantanés de voir ce que les objets et les classes ressemblait à de la mémoire. J'ai découvert que certains des énumérations de mon schéma XML utilisé dans mon CXF/JAXB (wsdl2java) classes générées ont été persistante après un undeployment. Selon mon tas de vidage on dirait que les objets étaient liées à une Carte. Avertissement: j'avoue que je suis encore un peu vert avec le profilage et de suivi d'un objet de l'arbre d'appel peut être difficile en Java.

Aussi, je tiens à mentionner que je n'ai même pas appeler le service, tout juste de déployer ensuite annulée. Les objets eux-mêmes semblaient être chargés via la réflexion entamée à partir du Printemps sur le déploiement. Je crois que j'ai suivi de la convention pour la création d'un CXF service au Printemps. Donc je ne suis pas sûr à 100% si c'est le Printemps/CXF, JAXB, de réflexion ou de la faute.

Comme une note de côté: l'application en question est un service web à l'aide de Printemps/CXF et le XML se trouve être plutôt un schéma complexe (une extension de NIEM).

Answer 1

Si vous voulez vous assurer de ne pas causer de fuites, vous devez faire ce qui suit:

• Assurez-vous que votre application web n'utilise pas de classes java qui sont dans le conteneur web des bibliothèques partagées. Si vous avez des bibliothèques partagées, assurez-vous il n'y a pas de solides références aux objets dans les bibliothèques
• Évitez d'utiliser des variables statiques, en particulier sur des objets java comme table de hachage, Jeux, etc. Si vous en avez besoin, assurez-vous que vous appelez supprimer pour libérer les objets avec les cartes, listes,...

C'est aussi un bon article sur ThreadLocal et MemoryLeaks - http://blog.arendsen.net/index.php/2005/02/22/threadlocals-and-memory-leaks-revisited/

Answer 2

Tomcat 7 est censé apporter des améliorations dans ce domaine. Voir les Fonctionnalités d'Apache Tomcat 7, section intitulée Pas Plus de Fuites!

Ils croient qu'ils peuvent maintenant faire face à beaucoup de fuites de mémoire causées par les applications web. Malheureusement, il est encore en version bêta.

Autre que cela, je peux juste dire que j'ai fait la même expérience et n'ont pas trouvé une solution. Le déploiement généralement nécessite le redémarrage de Tomcat par la suite. Je n'ai aucune idée de qui est le coupable est: mon application web, Tomcat, Hibernate, de Tapisserie ou de plusieurs d'entre eux.