2011-10-07 5 views
30

J'exécute une application web java en utilisant Hibernate et glassfish Server. Je reçoisErreur d'espace PermGen - Glassfish Server

java.lang.OutOfMemoryError: PermGen space exception quand je l'ai déployé plusieurs fois.

J'ai essayé -XX:MaxPermSize=128M dans mes variables d'environnement, mais cela ne fonctionne pas.

+0

Est-ce ce que vous recherchez: http://stackoverflow.com/questions/1996088/java-class-permgen-memory-leak-web-applications-generic-solution – Raedwald

Répondre

37

Ce chargeur de classe est fuite de mémoire. Chaque fois que vous redéployez l'application, un nouveau chargeur de classe est créé et toutes les classes de votre application sont à nouveau chargées. Cela consomme de la mémoire dans l'espace perm gén.

L'ancien classloader et toutes ses classes chargées doivent être collectés, sinon vous finirez par exécuter un espace OOME de PermGen après plusieurs déploiements. Cela ne fonctionne pas si un objet chargé par un chargeur de classe externe contient une référence à un objet chargé par l'ancien chargeur de classe. This article donne une bonne explication du problème.

Généralement, les fuites de classloader sont difficiles à analyser et parfois difficiles à réparer. Pour savoir pourquoi les anciens classloaders ne sont pas collectés, vous devez utiliser un profileur. Dans JProfiler, utilisez le séparateur de segments, sélectionnez les objets glassload classloader et utilisez la vue des références entrantes pour rechercher les chemins d'accès aux racines du récupérateur de place.

La classe du chargeur de classe est appelée org.apache.servlet.jasper.JasperLoader. Voici une capture d'écran d'une situation normale, où le chargeur de classe est uniquement détenu par des instances actives d'objets chargés.

enter image description here

Dans votre situation, vous devriez voir les références des objets extérieurs. Une autre cause fréquente d'une fuite de classloader dans les conteneurs Web est un thread d'arrière-plan qui n'est pas arrêté. Google Guice par exemple a un tel bug dans 3.0.

(non-responsabilité: mon entreprise se développe JProfiler)

5

Ce problème se produit plusieurs fois avec le déploiement itératif. J'ai fait face à cela plusieurs fois. S'il vous plaît consulter le lien ci-dessous pour JIRA bug GlassFish:

http://java.net/jira/browse/GLASSFISH-587

+1

Avez-vous vu l'année de ce rapport de bug? ?! –

46

Pour résoudre ce problème (en os à base de linux) ne suit

1) mémoire augmentation (de sorte que ce problème ne viennent pas souvent) par configurer "domaine".xml » dans

/GlassFish/domaine/domain1/config

recherche

<jvm-options>-XX:MaxPermSize=

set it to higher value eg- 198m or 256m

2) tuer le processus GlassFish pour libérer le port sur lequel il a été en cours d'exécution (dans mon cas, il était 8686) terminal ouvert (en OS linux) et le type -

sudo netstat -npl | grep 8686

cela se traduira par quelque chose comme ..

tcp6 0 0 :::8686 :::* LISTEN 3452/java

prochaine utilisation

kill -9 3452 pour tuer ce processus (3452 dans ce cas)

Maintenant, essayez de démarrer glassfish, il devrait commencer.

+0

merci monsieur! très bon! –

9

Si vous utilisez Windows, essayez de supprimer le processus glassfish (java.exe * 32) avec le Gestionnaire des tâches, puis redémarrez le serveur.

+0

C'est parfait –