it-swarm-eu.dev

Umgang mit dem Fehler "Java.lang.OutOfMemoryError: PermGen space"

Kürzlich bin ich in meiner Webanwendung auf folgenden Fehler gestoßen:

Java.lang.OutOfMemoryError: PermGen-Speicherplatz

Es ist eine typische Hibernate/JPA + IceFaces/JSF-Anwendung, die auf Tomcat 6 und JDK 1.6 ausgeführt wird. Anscheinend kann dies nach mehrmaliger erneuter Bereitstellung einer Anwendung auftreten.

Was verursacht es und was kann getan werden, um es zu vermeiden? Wie behebe ich das Problem?

1212
Chris

Die Lösung bestand darin, diese Flags zur JVM-Befehlszeile hinzuzufügen, wenn Tomcat gestartet wird:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Sie können dies tun, indem Sie den Tomcat-Dienst beenden, dann in das Verzeichnis Tomcat/bin wechseln und Tomcat6w.exe ausführen. Fügen Sie auf der Registerkarte "Java" die Argumente in das Feld "Java-Optionen" ein. Klicken Sie auf "OK" und starten Sie den Dienst neu.

Wenn Sie eine Fehlermeldung erhalten, dass der angegebene Dienst nicht als installierter Dienst existiert , sollten Sie Folgendes ausführen:

Tomcat6w //ES//servicename

dabei ist Servicename der Name des Servers, wie in services.msc angezeigt

Quelle: Kommentar von orx zu Eric's Agile Answers .

560
Chris

Versuchen Sie es lieber mit -XX:MaxPermSize=128M als mit _-XX:MaxPermGen=128M_.

Ich kann die genaue Verwendung dieses Speicherpools nicht feststellen, sie hängt jedoch mit der Anzahl der in die JVM geladenen Klassen zusammen. (Dadurch kann das Problem behoben werden, indem das Entladen von Klassen für Tomcat aktiviert wird.) Wenn Ihre Anwendungen Klassen während der Ausführung generieren und kompilieren, ist es wahrscheinlicher, dass ein größerer als der Standardspeicherpool erforderlich ist.

250
toesterdahl

Häufige Fehler, die Menschen machen, sind der Gedanke, dass der Haufenraum und der Permgenraum gleich sind, was überhaupt nicht wahr ist. Möglicherweise ist noch viel Speicherplatz auf dem Heap vorhanden, aber in permgen ist möglicherweise immer noch nicht genügend Arbeitsspeicher verfügbar.

Häufige Ursachen für OutofMemory in PermGen sind ClassLoader. Immer wenn eine Klasse in JVM geladen wird, werden alle ihre Metadaten zusammen mit Classloader im PermGen-Bereich gespeichert und werden müllsammelbar, wenn der Classloader, der sie geladen hat, für die Garbage Collection bereit ist. In dem Fall, dass Classloader einen Speicherverlust aufweist, bleiben alle von ihm geladenen Klassen im Speicher und verursachen permGen outofmemory, wenn Sie es ein paar Mal wiederholen. Das klassische Beispiel ist Java.lang.OutOfMemoryError: PermGen Space in Tomcat .

Nun gibt es zwei Möglichkeiten, dies zu lösen:
1. Finden Sie die Ursache für Memory Leak oder wenn es einen Speicherverlust gibt.
2. Erhöhen Sie die Größe von PermGen Space mithilfe der JVM-Parameter -XX:MaxPermSize und -XX:PermSize.

Sie können auch 2 Lösung von Java.lang.OutOfMemoryError in Java für weitere Details überprüfen.

67
Peter

Verwenden Sie den Befehlszeilenparameter -XX:MaxPermSize=128m für eine Sun-JVM (wobei Sie natürlich 128 für jede benötigte Größe einsetzen).

41
user17163

Versuchen Sie es mit -XX:MaxPermSize=256m, und wenn dies weiterhin der Fall ist, versuchen Sie es mit -XX:MaxPermSize=512m

37
bassist

I hinzugefügt-XX: MaxPermSize = 128m (Sie können experimentieren, was am besten funktioniert) zu VM-Argumenten , wenn ich Eclipse ide verwende . In den meisten JVMs ist Standardeinstellung PermSize ungefähr 64 MB , was den Arbeitsspeicher erschöpft, wenn zu viele Klassen oder eine große Anzahl von Klassen vorhanden sind Zeichenketten im Projekt.

Für Eclipse wird es auch unter answer beschrieben.

SCHRITT 1 : Doppelklicken Sie auf den Tomcat-Server auf der Registerkarte Server

enter image description here

SCHRITT 2 : Starten Sie Conf und fügen Sie -XX: MaxPermSize = 128m hinzu das Ende bestehender VM-Argumente .

enter image description here

27
prayagupd

Ich habe mich mit diesem Problem auseinandergesetzt, während ich eine komplexe Webanwendung bereitgestellt und wieder entfernt habe, und dachte, ich würde eine Erklärung und meine Lösung hinzufügen.

Wenn ich eine Anwendung auf Apache Tomcat bereitstelle, wird für diese Anwendung ein neuer ClassLoader erstellt. Der ClassLoader wird dann verwendet, um alle Klassen der Anwendung zu laden, und wenn die Bereitstellung aufgehoben wird, sollte alles in Ordnung sein. In Wirklichkeit ist es jedoch nicht ganz so einfach.

Eine oder mehrere der Klassen, die während der Laufzeit der Webanwendung erstellt wurden, enthalten einen statischen Verweis, der irgendwo auf den ClassLoader verweist. Da es sich bei der Referenz ursprünglich um eine statische Referenz handelt, wird diese Referenz durch keine Speicherbereinigung bereinigt - der ClassLoader und alle geladenen Klassen bleiben erhalten.

Nach einigen erneuten Implementierungen tritt der OutOfMemoryError auf.

Nun ist dies ein ziemlich ernstes Problem geworden. Ich könnte sicherstellen, dass Tomcat nach jeder erneuten Bereitstellung neu gestartet wird, aber dadurch wird der gesamte Server heruntergefahren und nicht nur die Anwendung, die erneut bereitgestellt wird. Dies ist häufig nicht möglich.

Also habe ich stattdessen eine Lösung in Code zusammengestellt, die auf Apache Tomcat 6.0 funktioniert. Ich habe auf keinem anderen Anwendungsserver getestet und muss betonen, dass dies wird sehr wahrscheinlich nicht ohne Änderung auf einem anderen Anwendungsserver funktionieren.

Ich möchte auch sagen, dass ich diesen Code persönlich hasse und dass niemand sollte dies als "schnelle Lösung" verwenden, wenn der vorhandene Code geändert werden kann, um die richtigen Methoden zum Herunterfahren und Bereinigen zu verwenden. Dies sollte nur verwendet werden, wenn es eine externe Bibliothek gibt, von der Ihr Code abhängig ist (in meinem Fall war es ein RADIUS -Client), der keine Möglichkeit bietet, seine eigenen statischen Referenzen zu bereinigen.

Wie auch immer, weiter mit dem Code. Dies sollte an dem Punkt aufgerufen werden, an dem die Anwendung die Bereitstellung aufhebt, z. B. bei der Destroy-Methode eines Servlets oder (besser gesagt) bei der contextDestroyed-Methode eines ServletContextListener.

//Get a list of all classes loaded by the current webapp classloader
WebappClassLoader classLoader = (WebappClassLoader) getClass().getClassLoader();
Field classLoaderClassesField = null;
Class clazz = WebappClassLoader.class;
while (classLoaderClassesField == null && clazz != null) {
    try {
        classLoaderClassesField = clazz.getDeclaredField("classes");
    } catch (Exception exception) {
        //do nothing
    }
    clazz = clazz.getSuperclass();
}
classLoaderClassesField.setAccessible(true);

List classes = new ArrayList((Vector)classLoaderClassesField.get(classLoader));

for (Object o : classes) {
    Class c = (Class)o;
    //Make sure you identify only the packages that are holding references to the classloader.
    //Allowing this code to clear all static references will result in all sorts
    //of horrible things (like Java segfaulting).
    if (c.getName().startsWith("com.whatever")) {
        //Kill any static references within all these classes.
        for (Field f : c.getDeclaredFields()) {
            if (Modifier.isStatic(f.getModifiers())
                    && !Modifier.isFinal(f.getModifiers())
                    && !f.getType().isPrimitive()) {
                try {
                    f.setAccessible(true);
                    f.set(null, null);
                } catch (Exception exception) {
                    //Log the exception
                }
            }
        }
    }
}

classes.clear();
22
Edward Torbett

Die Raumnachricht _Java.lang.OutOfMemoryError: PermGen_ zeigt an, dass der Speicherbereich der permanenten Generation erschöpft ist.

Alle Java Anwendungen dürfen eine begrenzte Menge an Speicher verwenden. Die genaue Speichermenge, die Ihre bestimmte Anwendung verwenden kann, wird beim Start der Anwendung angegeben.

Java-Speicher ist in verschiedene Bereiche unterteilt, die in der folgenden Abbildung dargestellt sind:

enter image description here

Metaspace: Ein neuer Speicherplatz entsteht

Die JDK 8-HotSpot-JVM verwendet jetzt den nativen Speicher für die Darstellung von Klassenmetadaten und heißt Metaspace. ähnlich wie bei Oracle JRockit und IBM JVM.

Die gute Nachricht ist, dass es keine _Java.lang.OutOfMemoryError: PermGen_ Speicherplatzprobleme mehr gibt und Sie diesen Speicherplatz nicht mehr mit Java_8_Download oder höher einstellen und überwachen müssen.

17
Santosh Jadi

1) Erhöhen der PermGen-Speichergröße

Das Erste, was Sie tun können, ist, den Heap-Speicherplatz der permanenten Generation zu vergrößern. Dies ist mit den üblichen JVM-Argumenten –Xms (anfängliche Heap-Größe festlegen) und –Xmx (maximale Heap-Größe festlegen) nicht möglich, da der permanente Generierungs-Heap-Speicherplatz, wie erwähnt, vollständig vom regulären Java-Heap getrennt ist space, und diese Argumente legen den Platz für diesen regulären Java Heap-Platz fest. Es gibt jedoch ähnliche Argumente, die verwendet werden können (zumindest mit Sun/OpenJDK-JVMS), um die Größe des permanenten Generationsheaps zu vergrößern:

 -XX:MaxPermSize=128m

Die Standardeinstellung ist 64 m.

2) Aktivieren Sie Sweeping

Eine andere Möglichkeit, dies endgültig zu erledigen, besteht darin, das Entladen von Klassen zuzulassen, damit Ihr PermGen niemals leer wird:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Solche Sachen haben in der Vergangenheit für mich magisch gewirkt. Eine Sache ist jedoch, dass sich die Verwendung dieser Anforderungen in erheblichem Maße auf die Leistung auswirkt, da Permgen-Sweeps für jede von Ihnen gestellte Anfrage oder eine ähnliche Anfrage zwei zusätzliche Anfragen stellen. Sie müssen Ihre Nutzung mit den Kompromissen abwägen.

Sie können die Details dieses Fehlers finden.

http://faisalbhagat.blogspot.com/2014/09/Java-outofmemoryerror-permgen.html

15
faisalbhagat

Alternativ können Sie zu JRockit wechseln, das Permgen anders behandelt als Suns jvm. Es hat im Allgemeinen auch eine bessere Leistung.

http://www.Oracle.com/technetwork/middleware/jrockit/overview/index.html

15
Jeremy

Die einfachste Antwort heutzutage ist die Verwendung von Java 8.

Es reserviert keinen Speicher mehr ausschließlich für den PermGen-Speicher, sodass sich der PermGen-Speicher mit dem regulären Speicherpool vermischen kann.

Beachten Sie, dass Sie alle nicht standardmäßigen -XXPermGen...=... JVM-Startparameter entfernen müssen, wenn Sie nicht möchten, dass Java 8 beschwert, dass sie nichts tun.

13
Edwin Buck

Ich hatte das Problem, über das wir hier sprechen, mein Szenario ist Eclipse-helios + Tomcat + jsf und Sie haben eine einfache Anwendung für Tomcat bereitgestellt. Ich zeigte das gleiche Problem hier, löste es wie folgt.

In Eclipse gehen Sie auf die Registerkarte Server Doppelklicken Sie auf den registrierten Server in meinem Fall Tomcat 7.0, es öffnet sich mein Dateiserver Allgemeine Registrierungsinformationen. Klicken Sie im Abschnitt "Allgemeine Informationen" auf den Link "Startkonfiguration öffnen", um die Ausführung von Serveroptionen auf der Registerkarte "Argumente" in VM zu öffnen. Argumente hinzugefügt am Ende dieser beiden Einträge

-XX: MaxPermSize = 512m
-XX: PermSize = 512m

und fertig.

13
Hugo Mendoza
  1. Öffnen Sie Tomcat7w aus dem bin-Verzeichnis von Tomcat oder geben Sie Monitor Tomcat im Startmenü ein (ein Fenster mit Registerkarten mit verschiedenen Dienstinformationen wird geöffnet).
  2. Fügen Sie im Textbereich Java Options folgende Zeile hinzu:

    -XX:MaxPermSize=128m
    
  3. Setzen Sie den anfänglichen Speicherpool auf 1024 (optional).
  4. Setzen Sie den maximalen Speicherpool auf 1024 (optional).
  5. OK klicken.
  6. Starten Sie den Tomcat-Dienst neu.
8
Lucky

Perm gen space error tritt auf, weil zum Ausführen des Codes viel Speicherplatz verwendet wird, anstatt von jvm bereitgestelltem Speicherplatz. Die beste Lösung für dieses Problem unter UNIX-Betriebssystemen besteht darin, einige Einstellungen in der Bash-Datei zu ändern. Die folgenden Schritte lösen das Problem.

Führen Sie den Befehl gedit .bashrc auf dem Terminal aus.

Erstellen Sie die Variable Java_OTPS mit folgendem Wert:

export Java_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m"

Speichern Sie die Bash-Datei. Führen Sie den Befehl exec bash auf dem Terminal aus. Starten Sie den Server neu.

Ich hoffe, dass dieser Ansatz bei Ihrem Problem funktioniert. Wenn Sie eine Java -Version kleiner als 8 verwenden, tritt dieses Problem manchmal auf. Wenn Sie jedoch Java 8 verwenden, tritt das Problem nie auf.

6
Darshan

Wenn Sie einen echten Speicherverlust haben, hilft es NICHT, die Größe der permanenten Generierung zu erhöhen oder die GC-Parameter zu optimieren. Wenn Ihre Anwendung oder eine von ihr verwendete Bibliothek von Drittanbietern Klassenladeprogramme verliert, besteht die einzige echte und dauerhafte Lösung darin, dieses Leck zu finden und zu beheben. Es gibt eine Reihe von Tools, die Ihnen helfen können. Eines der neuesten ist Plumbr , das gerade eine neue Version mit den erforderlichen Funktionen herausgebracht hat.

5
Nikem

Wenn Sie log4j in Ihrer Webanwendung verwenden, überprüfen Sie diesen Absatz in log4j Dokumentation .

Es scheint, dass bei Verwendung von PropertyConfigurator.configureAndWatch("log4j.properties") Speicherverluste auftreten, wenn Sie die Bereitstellung Ihrer Webanwendung aufheben.

5

jrockit hat das auch für mich gelöst; Mir ist jedoch aufgefallen, dass die Servlet-Neustartzeiten viel schlechter waren, so dass es zwar in der Produktion besser war, aber ein gewisser Entwicklungsschub war.

4
Tim Howland

Ich habe eine Kombination aus Hibernate + Eclipse RCP, habe versucht, -XX:MaxPermSize=512m und -XX:PermSize=512m zu verwenden, und es scheint für mich zu funktionieren.

4
Pankaj Shinde

Ich habe mehrere Antworten ausprobiert und das einzige, was letztendlich den Job gemacht hat, war die Konfiguration für das Compiler-Plugin im POM:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <fork>true</fork>
        <meminitial>128m</meminitial>
        <maxmem>512m</maxmem>
        <source>1.6</source>
        <target>1.6</target>
        <!-- prevent PermGen space out of memory exception -->
        <!-- <argLine>-Xmx512m -XX:MaxPermSize=512m</argLine> -->
    </configuration>
</plugin>

hoffe das hilft.

4
kiwilisk

Stellen Sie -XX:PermSize=64m -XX:MaxPermSize=128m ein. Später können Sie auch versuchen, MaxPermSize zu erhöhen. Ich hoffe, es wird funktionieren. Das gleiche funktioniert bei mir. Die Einstellung nur MaxPermSize hat bei mir nicht funktioniert.

4
sandeep

Das Zuweisen von mehr Speicher für Tomcat ist NICHT die richtige Lösung.

Die richtige Lösung besteht darin, eine Bereinigung durchzuführen, nachdem der Kontext zerstört und neu erstellt wurde (Hot Deploy). Die Lösung besteht darin, die Speicherlecks zu stoppen.

Wenn Ihr Tomcat/Webapp-Server Ihnen mitteilt, dass die Registrierung von Treibern (JDBC) nicht aufgehoben werden konnte, heben Sie die Registrierung auf. Dadurch werden die Speicherverluste gestoppt.

Sie können einen ServletContextListener erstellen und in Ihrer web.xml konfigurieren. Hier ist ein Beispiel für einen ServletContextListener:

import Java.sql.Driver;
import Java.sql.DriverManager;
import Java.sql.SQLException;
import Java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.Apache.log4j.Logger;

import com.mysql.jdbc.AbandonedConnectionCleanupThread;

/**
 * 
 * @author alejandro.tkachuk / calculistik.com
 *
 */
public class AppContextListener implements ServletContextListener {

    private static final Logger logger = Logger.getLogger(AppContextListener.class);

    @Override
    public void contextInitialized(ServletContextEvent arg0) {
        logger.info("AppContextListener started");
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0) {
        logger.info("AppContextListener destroyed");

        // manually unregister the JDBC drivers
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
                logger.info(String.format("Unregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                logger.info(String.format("Error unregistering driver %s", driver), e);
            }

        }

        // manually shutdown clean up threads
        try {
            AbandonedConnectionCleanupThread.shutdown();
            logger.info("Shutting down AbandonedConnectionCleanupThread");
        } catch (InterruptedException e) {
            logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
            e.printStackTrace();
        }        
    }
}

Und hier konfigurieren Sie es in Ihrer web.xml:

<listener>
    <listener-class>
        com.calculistik.mediweb.context.AppContextListener 
    </listener-class>
</listener>  

Sie sagen, dass die neueste Version von Tomcat (6.0.28 oder 6.0.29) die Aufgabe des erneuten Bereitstellens von Servlets übernimmt viel besser.

3
Tony Ennis

In diesem Fall muss zunächst geprüft werden, ob der GC Klassen aus PermGen entladen darf. Die Standard-JVM ist in dieser Hinsicht eher konservativ - Klassen werden geboren, um für immer zu leben. Sobald die Klassen geladen sind, bleiben sie im Speicher, auch wenn kein Code sie mehr verwendet. Dies kann zu einem Problem werden, wenn die Anwendung viele Klassen dynamisch erstellt und die generierten Klassen für längere Zeiträume nicht benötigt werden. In einem solchen Fall kann es hilfreich sein, der JVM das Entladen von Klassendefinitionen zu ermöglichen. Dies kann erreicht werden, indem Sie Ihren Startskripten nur einen Konfigurationsparameter hinzufügen:

-XX:+CMSClassUnloadingEnabled

Standardmäßig ist dies auf false gesetzt. Um dies zu aktivieren, müssen Sie die folgende Option in den Java -Optionen explizit festlegen. Wenn Sie CMSClassUnloadingEnabled aktivieren, durchsucht GC auch PermGen und entfernt Klassen, die nicht mehr verwendet werden. Beachten Sie, dass diese Option nur funktioniert, wenn UseConcMarkSweepGC auch mit der folgenden Option aktiviert ist. Wenn Sie also ParallelGC oder, Gott bewahre, Serial GC ausführen, stellen Sie sicher, dass Sie Ihren GC auf CMS eingestellt haben, indem Sie Folgendes angeben:

-XX:+UseConcMarkSweepGC
3
sendon1982

Ich habe genau dasselbe Problem, aber leider hat keine der vorgeschlagenen Lösungen für mich wirklich funktioniert. Das Problem ist während der Bereitstellung nicht aufgetreten, und ich habe auch keine Hot-Deployments durchgeführt.

In meinem Fall trat das Problem jedes Mal zur gleichen Zeit während der Ausführung meiner Webanwendung auf, während ich mich (über den Ruhezustand) mit der Datenbank verband.

Dieser Link (auch oben erwähnt) hat genügend Insides bereitgestellt, um das Problem zu lösen. Das Verschieben des jdbc- (mysql) -Treibers aus dem WEB-INF in den Ordner jre/lib/ext/scheint das Problem gelöst zu haben. Dies ist nicht die ideale Lösung, da Sie für ein Upgrade auf eine neuere JRE den Treiber neu installieren müssen. Ein anderer Kandidat, der ähnliche Probleme verursachen könnte, ist log4j. Vielleicht möchten Sie diesen auch verschieben

3
Maze

Die Konfiguration des Speichers hängt von der Art Ihrer App ab.

Was machen Sie?

Wie viele Transaktionen sind erforderlich?

Wie viele Daten laden Sie?

usw.

usw.

usw

Wahrscheinlich könnten Sie Ihre App profilieren und einige Module aus Ihrer App entfernen.

Anscheinend kann dies nach mehrmaliger erneuter Bereitstellung einer Anwendung auftreten.

Tomcat wird im laufenden Betrieb bereitgestellt, verbraucht jedoch Speicher. Versuchen Sie ab und zu, den Container neu zu starten. Außerdem müssen Sie wissen, wie viel Speicher erforderlich ist, um im Produktionsmodus ausgeführt zu werden. Dies scheint ein guter Zeitpunkt für diese Recherche zu sein.

3
OscarRyz

Wenn Sie dies in der Eclipse-IDE erhalten, obwohl Sie die Parameter --launcher.XXMaxPermSize, -XX:MaxPermSize usw. eingestellt haben, ist es höchstwahrscheinlich, dass die Eclipse einen Buggy verwendet, wenn derselbe Fehler auftritt JRE-Version, die von einigen Drittanbieteranwendungen installiert und auf Standard gesetzt worden wäre. Bei diesen fehlerhaften Versionen werden die PermSize-Parameter nicht erfasst. Unabhängig davon, was Sie einstellen, werden diese Speicherfehler weiterhin angezeigt. Fügen Sie in Ihrer Eclipse.ini die folgenden Parameter hinzu:

-vm <path to the right JRE directory>/<name of javaw executable>

Stellen Sie außerdem sicher, dass Sie in den Einstellungen in Eclipse als Standard-JRE die richtige Java-Version festgelegt haben.

2

Der einzige Weg, der für mich funktioniert hat, war mit der JRockit JVM. Ich habe MyEclipse 8.6.

Der Heap der JVM speichert alle Objekte, die von einem ausgeführten Programm Java generiert wurden. Java verwendet den Operator new, um Objekte zu erstellen, und Speicher für neue Objekte wird zur Laufzeit auf dem Heap zugewiesen. Garbage Collection ist der Mechanismus zum automatischen Freigeben des Speichers, der in den Objekten enthalten ist, auf die das Programm nicht mehr verweist.

2
Daniel

Ich hatte ein ähnliches Problem. Meins ist JDK 7 + Maven 3.0.2 + Struts 2.0 + auf Google GUICE-Abhängigkeit basierendes injektionsbasiertes Projekt.

Immer wenn ich versuchte, den Befehl mvn clean package auszuführen, wurde der folgende Fehler angezeigt und "BUILD FAILURE" trat auf

org.Apache.maven.surefire.util.SurefireReflectionException: Java.lang.reflect.InvocationTargetException; verschachtelte Ausnahme ist Java.lang.reflect.InvocationTargetException: null Java.lang.reflect.InvocationTargetException. OutOfMemoryError: PermGen space

Ich habe alle oben genannten nützlichen Tipps und Tricks ausprobiert, aber leider hat keine für mich funktioniert. Was bei mir funktioniert hat, wird nachfolgend Schritt für Schritt beschrieben: =>

  1. Gehen Sie zu Ihrer pom.xml
  2. Suche nach _<artifactId>maven-surefire-plugin</artifactId>_
  3. Fügen Sie ein neues _<configuration>_ -Element und dann ein _<argLine>_ -Unterelement hinzu, in dem Sie _-Xmx512m -XX:MaxPermSize=256m_ übergeben (siehe unten) =>

<configuration> <argLine>-Xmx512m -XX:MaxPermSize=256m</argLine> </configuration>

Hoffe es hilft, viel Spaß beim Programmieren :)

2

"Sie" sind falsch, weil ich 6.0.29 ausführe und das gleiche Problem habe, auch wenn ich alle Optionen gesetzt habe. Wie Tim Howland oben sagte, haben diese Optionen nur das Unvermeidliche aufgeschoben. Sie ermöglichen mir, drei Mal erneut bereitzustellen, bevor der Fehler angezeigt wird, anstatt bei jeder erneuten Bereitstellung.

2
Ross Peoples

Sie können dieses Problem auch lösen, indem Sie Folgendes ausführen:

rm -rf <Tomcat-dir>/work/* <Tomcat-dir>/temp/*

Durch das Löschen der Verzeichnisse work und temp führt Tomcat einen sauberen Start durch.

1
dev

Wenn jemand mit demselben Fehler in Netbeans zu kämpfen hat, habe ich ihn folgendermaßen behoben.

In Netbeans:

Gehen Sie zur Registerkarte Dienste -> Rechts auf dem Server -> Wählen Sie Eigenschaften -> Gehen Sie zur Registerkarte Plattform -> Geben Sie in VM-Optionen -Xms1024m ein

In meinem Fall habe ich -Xms4096m angegeben

Hier ist der Screenshot:

enter image description here

0
Satyadev