J'exécute une application Web Java en utilisant Hibernate et Glassfish Server. Je reçois
java.lang.OutOfMemoryError: PermGen space exception lorsque je l'ai déployé plusieurs fois.
J'ai essayé -XX:MaxPermSize=128M dans mes variables d'environnement, mais cela ne fonctionne pas.
Pour résoudre ce problème ( basé sur linux os ) faire à la suite
1) augmentation de la mémoire (de sorte que ce problème ne viens pas souvent ) par la configuration "domain.xml" dans
/glassfish/domaine/domain1/config
recherche pour
<jvm-options>-XX:MaxPermSize=
set it to higher value eg- 198m or 256m
2) tuer glassfish processus afin de libérer le port sur lequel il a été en cours d'exécution ( dans mon cas c'était 8686) ouvrir un terminal (dans le système d'exploitation basé sur linux) et de type
sudo netstat -npl | grep 8686
il en résultera quelque chose comme..
tcp6 0 0 :::8686 :::* LISTEN 3452/java
à la prochaine utilisation
kill -9 3452 de tuer le processus ( 3452 dans ce cas )
Maintenant, essayez de démarrer glassfish, il doit démarrer.
C'est le chargeur de classes de fuite de mémoire. Chaque fois que vous redéployer l'application, un nouveau chargeur de classe est créée pour lui et toutes les classes de votre application sont de nouveau chargé. Cela consomme de la mémoire dans la région de perm gen de l'espace.
L'ancien chargeur de classe et tous ses classes chargées, doivent être des ordures collectées, sinon vous allez finir par courir dans une PermGen space OOME après le déploiement de plusieurs fois. Cela ne fonctionne pas si un objet chargé par un chargeur de classe contient une référence à un objet chargé par l'ancien chargeur de classe. Cet article donne une bonne explication de ce problème.
Généralement, chargeur de classe fuites sont difficiles à analyser, et parfois difficiles à corriger. Pour savoir pourquoi les vieux chargeurs de classes ne sont pas des ordures collectées, vous devez utiliser un profiler. Dans JProfiler, utilisez le segment, sélectionnez la glassfish chargeur de classes d'objets et d'utiliser les entrants références vue de vérifier les chemins d'accès à garbage collector racines.
Le chargeur de classe de classe est appelée org.apache.servlet.jasper.JasperLoader. Voici une capture d'écran d'une situation régulière, où le chargeur de classe n'est tenue que par vivre les instances des objets chargés.
Dans votre situation, vous devriez voir des références à partir de l'extérieur des objets. Une autre cause fréquente d'un chargeur de classe de fuite dans des conteneurs web est un thread d'arrière-plan qui n'est pas arrêté. Google Guice, par exemple, a un bogue dans la version 3.0.
(Avertissement: mon entreprise se développe JProfiler)
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
