PermGen Fehler Tomcat8/Spring Data/Hibernate bei Bereitstellung

Question

Wenn Sie mit einer Webanwendung arbeiten, die Tomcat8/Spring MVC/Spring Date/Hibernate verwendet, werden alle paar Bereitstellungen auf dem Server oder sogar in der Java-Entwicklungsumgebung den folgenden Fehler verursachen. Weiß jemand, wie ich das vermeiden oder beheben kann? Ich habe versucht, die JVM zu erhöhen, um mehr Speicher ohne Erfolg zu haben. Der Frühling ist mit dem Setup-Java-Konfigurationsdateien und nicht die alte web.xml Methode

[ContainerBackgroundProcessor[StandardEngine[Catalina]]] ERROR org.springframework.web.context.ContextLoader - Context initialization failed 
 
java.lang.OutOfMemoryError: PermGen space 
 
\t at java.lang.ClassLoader.defineClass1(Native Method) 
 
\t at java.lang.ClassLoader.defineClass(ClassLoader.java:800) 
 
\t at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
 
\t at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2494) 
 
\t at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:860) 
 
\t at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1302) 
 
\t at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167) 
 
\t at org.springframework.util.ConcurrentReferenceHashMap$EntrySet.iterator(ConcurrentReferenceHashMap.java:794) 
 
\t at java.util.AbstractMap$1$1.<init>(AbstractMap.java:322) 
 
\t at java.util.AbstractMap$1.iterator(AbstractMap.java:321) 
 
\t at org.springframework.beans.CachedIntrospectionResults.clearClassLoader(CachedIntrospectionResults.java:164) 
 
\t at org.springframework.context.support.AbstractApplicationContext.resetCommonCaches(AbstractApplicationContext.java:881) 
 
\t at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:563) 
 
\t at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:446) 
 
\t at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:328) 
 
\t at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:107) 
 
\t at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4810) 
 
\t at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5255) 
 
\t at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) 
 
\t at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3831) 
 
\t at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:292) 
 
\t at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5616) 
 
\t at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1377) 
 
\t at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381) 
 
\t at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381) 
 
\t at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1349) 
 
\t at java.lang.Thread.run(Thread.java:745) 
 
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" java.lang.OutOfMemoryError: PermGen space

Answer 1

ich andere Tomcat PermGen Probleme gesehen haben, so würde ich zunächst versuchen, diese Argumente verwenden, um zu sehen, ob es ausreichend, bevor Sie Ihre PermGen-Größe erhöhen.

-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled 

Wenn das nicht funktioniert, überprüfen Sie, um PermGen und nicht die Größe des Heap zu erhöhen. Sie können die PermGen-Größe mit dem folgenden JVM-Argument festlegen: -XX:MaxPermSize=256M

Answer 2

Dies passiert, weil Ihre Anwendung nicht sauber undepploy wird. Sie erhalten den Fehler bei Speichern in Ihrer Entwicklungsumgebung, da dies wahrscheinlich eine erneute Bereitstellung Ihrer Anwendung auslöst.

diese Art von Fehler ist wirklich schwer zu debuggen, und wenn Sie die Ursache finden Sie möglicherweise nicht in der Lage, das Problem selbst zu lösen, weil eine Bibliothek, die Sie verwenden könnte der Fehler sein. Eine gute Lektüre zum Aufspüren dieser Art von Fehlern finden Sie hier: https://plumbr.eu/blog/memory-leaks/hunting-down-memory-leaks-a-case-study.

Ich hatte das gleiche Problem vor Jahren, und es stellte sich heraus, ein Problem in log4j. Am Ende haben wir den einfachen Ausweg genommen und beschlossen, den Anwendungsserver neu zu starten, anstatt die Anwendung erneut zu implementieren.

Dies ist einer der Gründe, warum viele Projekte heutzutage eine App pro Anwendungsserver bereitstellen (oder den Server einbetten) und einfach das Ganze bei Änderungen neu starten.

nichtsdestoweniger, wenn Sie die Zeit haben, lohnt es sich, dies zu verfolgen, weil es könnte ein Konfigurationsfehler sein. und Sie erfahren viel über Ihre App und deren Laufzeit.

Answer 3

Hoffentlich können Sie das Problem lösen, indem Sie einfach meine ClassLoader Leak Prevention library zu Ihrer Anwendung hinzufügen. Zum Zeitpunkt des Schreibens dieses Artikels, bedeutet, dass diese Maven Abhängigkeit

<dependency> 
    <groupId>se.jiderhamn</groupId> 
    <artifactId>classloader-leak-prevention</artifactId> 
    <version>1.15.2</version> 
</dependency> 

Plus in Ihrem web.xml (wird nicht in der Version 2 bald erforderlich sein, um veröffentlicht werden):

<listener> 
    <listener-class>se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor</listener-class> 
</listener> 

Um mehr über dritter zu lernen Party-Bibliotheken, die dieses Problem verursachen können, und erfahren Sie, wie Sie dies in Ihrem eigenen Code und externen Bibliotheken debuggen können, siehe this blog series of mine.