Umgang mit „java.lang.OutOfMemoryError:Fehler „PermGen-Speicherplatz“.

https://stackoverflow.com/questions/88235

01-07-2019
|

Frage

Kürzlich ist in meiner Webanwendung dieser Fehler aufgetreten:

java.lang.OutOfMemoryError:PermGen-Raum

Es handelt sich um eine typische Hibernate/JPA + IceFaces/JSF-Anwendung, die auf Tomcat 6 und JDK 1.6 läuft.Anscheinend kann dies nach mehrmaliger erneuter Bereitstellung einer Anwendung auftreten.

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

Lösung

Die Lösung wurde diese Flags zu JVM-Befehlszeile hinzuzufügen, wenn Tomcat gestartet wird:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Das können Sie den Tomcat-Dienst durch Herunterfahren, dann tomcat6w.exe gehen in die Tomcat / bin und ausgeführt wird. Unter den „Java“ Registerkarte, fügen Sie die Argumente für die „Java-Optionen“ -Box. Klicken Sie auf „OK“ und dann den Dienst neu zu starten.

Wenn Sie einen Fehler der angegebene Dienst existiert nicht als installierter Dienst sollten Sie laufen:

tomcat6w //ES//servicename

Dabei steht service ist der Name des Servers, wie in services.msc betrachtet

Quelle: orx Kommentar auf Erics Agile Antworten

Andere Tipps

Versuchen Sie es besser -XX:MaxPermSize=128M statt -XX:MaxPermGen=128M.

Ich kann die genaue Verwendung dieses Speicherpools nicht sagen, aber es hängt mit der Anzahl der in die JVM geladenen Klassen zusammen.(Daher kann das Problem durch Aktivieren des Entladens von Klassen für Tomcat behoben werden.) Wenn Ihre Anwendungen Klassen während der Ausführung generieren und kompilieren, ist es wahrscheinlicher, dass sie einen größeren Speicherpool als den Standardwert benötigen.

App-Server PermGen Fehler, die nach mehreren Einsätzen passieren werden höchstwahrscheinlich durch den Behälter in Ihre alten apps' Classloader gehalten durch Verweise verursacht. Zum Beispiel wird eine benutzerdefinierte Protokollebene Klasse mit Referenzen bewirken durch den Klassenlader App-Server statt. Sie können diese Inter-Classloader Lecks erkennen durch moderne mit (JDK6 +) JVM Analysetools wie jmap und jhat bei denen suchen Klassen in Ihrer Anwendung gehalten werden fortzusetzen und Redesign oder deren Verwendung zu beseitigen. Üblich Verdächtigen sind Datenbanken, Logger und andere Basis-Framework-Ebene Bibliotheken.

Siehe Classloader Lecks: die gefürchteten „java.lang .OutOfMemoryError: PermGen space“Ausnahme , und vor allem seine followup Post .

Häufige Fehler, die Menschen machen, ist, dass Heap-Speicher und Permgen Raum zu denken sind die gleichen, was nicht wahr ist. Sie könnten viel Platz in der Halde verbleibenden haben aber immer noch nicht genügend Arbeitsspeicher in Permgen laufen.

Häufige Ursachen für OutofMemory in PermGen ist Classloader. Jedes Mal, wenn eine Klasse in JVM geladen wird, werden alle seine Meta-Daten, zusammen mit Classloader wird auf einer Fläche PermGen gehalten und werden sie Müll gesammelt werden, wenn der Classloader, die sie ist für die Garbage Collection bereit geladen. In der Rechtssache hat Classloader ein Speicherleck als alle von ihm geladenen Klassen wird in Erinnerung bleiben und PermGen verursachen OutOfMemory, wenn Sie es ein paar Mal wiederholen. Das klassische Beispiel ist java.lang.OutOfMemoryError: PermGen Raum in Tomcat .

Nun gibt es zwei Möglichkeiten, dieses Problem zu lösen:
Finden 1. Ursache von Speicherverlust oder wenn es irgendein Speicherleck.
2. Erhöhung Größe PermGen Space von JVM param -XX:MaxPermSize und -XX:PermSize verwendet wird.

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

Verwenden Sie den Befehlszeilenparameter -XX:MaxPermSize=128m für eine Sun JVM (offensichtlich Substitution 128 für was Größe Sie benötigen).

Versuchen -XX:MaxPermSize=256m und wenn es weiterhin besteht, versuchen -XX:MaxPermSize=512m

hinzugefügt -XX: MaxPermSize = 128m (können Sie experimentieren, was am besten funktioniert) auf VM Argumente , wie ich ist eclipse IDE. In den meisten JVM, Standard PermSize ist um 64MB , die über genügend Arbeitsspeicher ausgeführt, wenn es zu viele Klassen oder große Anzahl von Strings in dem Projekt ein.

Für Eclipse ist es auch unter Antwort beschrieben.

Schritt 1: : Doppelklicken Sie auf den Tomcatbediener auf Server Tab

eingeben Bild Beschreibung hier

SCHRITT 2 : Öffnen Start Conf und fügen Sie -XX: MaxPermSize = 128m bis zum Ende der vorhandenen VM arguements .

eingeben Bild Beschreibung hier

Ich habe meinen Kopf gegen dieses Problem wurde Butting, während die Bereitstellung und undeploying eine komplexe Web-Anwendung zu, und dachte, dass ich eine Erklärung hinzufügen würde und meine Lösung.

Wenn ich eine Anwendung auf Apache Tomcat einsetzen, ein neuen Classloader ist für diese App erstellt. Der Classloader wird dann verwendet, um alle Klassen ist die Anwendung zu laden und auf undeploy, alles sollte gut gehen weg. Allerdings ist es nicht ganz in der Wirklichkeit so einfach.

Ein oder mehrere der Klassen während der Web-Anwendung des Lebens geschaffen haben einen statischen Verweis, die irgendwo entlang der Linie, die Classloader verweist. Da die Referenz ursprünglich statisch ist, wird kein Betrag von Mülleinsammlungs diese Referenz aufzuräumen - Classloader und alle Klassen es geladen wird, sind hier zu bleiben

Und nach ein paar redeploys begegnen uns die OutOfMemoryError.

Nun hat dies ein ziemlich ernstes Problem geworden. Ich könnte sicherstellen, dass Tomcat nach jedem redeploy neu gestartet wird, aber das dauert den gesamten Server herunter, und nicht nur die Anwendung umgeschichtet werden, was oft nicht machbar.

Also anstatt habe ich zusammen in Code eine Lösung setzen, die auf Apache Tomcat 6.0 funktioniert. Ich habe nicht auf anderen Anwendungsservern getestet und muss betonen, dass dies nicht sehr wahrscheinlich ist, ohne Änderungen auf einem anderen Anwendungsserver zu arbeiten .

Ich mag auch sagen, dass ich persönlich diesen Code hassen, und das sollte niemand mit diesem als „schnellen Lösung“, wenn der vorhandene Code geändert werden kann ordnungsgemäße Herunterfahren und Reinigungsmethoden verwenden . Das einzige Mal, das verwendet werden sollte, ist, wenn es eine externe Bibliothek Code auf abhängig ist (in meinem Fall war es ein RADIUS-Client), die keine Mittel bereitstellt seine eigene statische Referenzen aufzuräumen.

Wie auch immer, auf dem Code. Dies sollte an der Stelle genannt werden, in denen die Anwendung undeploying -. Wie ein zerstören Servlet-Methode oder (der besseren Ansatz) ein contextDestroyed Methode des 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();

Alternativ können Sie auf JRockit wechseln, die dann Sonne Jvm Permgen anders handhaben. Es hat in der Regel auch eine bessere Leistung.

http://www.oracle.com/technetwork/middleware/ jrockit / Übersicht / index.html

1) Erhöhung der PermGen Speichergröße

Das erste, was man tun kann, ist die Größe des permanenten Generation Heap-Speicher zu vergrößern. Dies kann nicht mit dem üblichen -Xms (Set anfängliche Heapgröße) und -Xmx (eingestellte maximale Speichergröße) JVM Argumente durchgeführt werden, da wie erwähnt, der permanente Generation Heap-Speicher ist völlig getrennt von dem regulären Java Heap-Speicher, und diese Argumente den Raum für diesen regelmäßigen Java Heap-Speicher festgelegt. Allerdings gibt es ähnliche Argumente, die (zumindest mit der Sonne / OpenJDK JVMs) verwendet werden können, um die Größe der Permanent Generation Heap größer zu machen:

 -XX:MaxPermSize=128m

Der Standardwert ist 64m.

2) Aktivieren Fegen

Eine andere Möglichkeit, das kümmern für gut Klassen zu ermöglichen, entladen werden, damit Ihr PermGen nie abläuft:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Sachen wie das funktionierte Magie für mich in der Vergangenheit. Eine Sache, aber es gibt eine deutliche Leistungs Trade-off diejenigen in Verwendung, da Permgen fegt wie eine zusätzliche 2-Anfragen machen wird für jede Anfrage Sie machen oder etwas in diese Richtung. Sie müssen Ihre Verwendung mit den Kompromissen balancieren.

Sie können die Details dieses Fehlers finden.

http://faisalbhagat.blogspot.com/2014/09/ java-OutOfMemoryError-permgen.html

Die java.lang.OutOfMemoryError: PermGen Raum Meldung zeigt an, dass der Bereich des Permanent-Generation im Speicher erschöpft ist.

Jede Java-Anwendungen erlaubt ist, eine begrenzte Menge an Speicher zu verwenden. Die genaue Menge an Speicher Ihrer Anwendung verwenden können, während Start der Anwendung angegeben wird.

Java-Speicher in verschiedene Bereiche getrennt ist, die in dem folgenden Bild zu sehen ist:

metaSpace: Ein neuer Speicherplatz wird geboren

Das JDK 8 HotSpot JVM wird jetzt mit nativen Speicher für die Darstellung von Klassen Metadaten und wird metaSpace genannt; ähnlich wie die Oracle JRockit und IBM JVM.

Die gute Nachricht ist, dass es bedeutet, nicht mehr java.lang.OutOfMemoryError: PermGen Platzprobleme und keine Notwendigkeit für Sie zu stimmen und überwachen diesen Speicherplatz mehr mit Java_8_Download oder höher.

ich das Problem hatten wir hier reden, ist mein Szenario Eclipse-helios + Kater + JSF und was Sie taten macht eine deploy eine einfache Anwendung zu Katers. Ich zeigte das gleiche Problem hier, löste es wie folgt.

In Eclipse geht auf Server Doppelklick auf dem registrierten Server in meinem Fall tomcat 7.0, öffnet es meine Dateiserver Allgemeiner Registrierungsinformationen. Auf dem Abschnitt „Allgemein“ klicken Sie auf dem Link „Open Startkonfiguration“ , öffnet dies die Ausführung von Serveroptionen in den Argumenten Registerkarte in VM Argumenten am Ende hinzugefügt dieses zwei Einträge

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

und fertig.

Die einfachste Antwort in diesen Tagen ist Java 8. verwenden

Es ist keine Reserven mehr Speicher ausschließlich für PermGen Raum, der PermGen Speicher ermöglicht mit dem regulären Speicherpool zusammen mischen.

Beachten Sie, dass Sie alle Nicht-Standard--XXPermGen...=... JVM-Startparameter entfernen müssen, wenn Sie 8 wollen Java nicht beklagen, dass sie nichts tun.

Öffnen tomcat7w von Tomcat-bin-Verzeichnis oder Typ-Monitor Tomcat in Startmenü (A Tabbed-Fenster öffnet sich mit verschiedenen Service-Informationen).
In dem Java-Optionen Textbereich hängen, um diese Zeile:
```
-XX:MaxPermSize=128m
```
Stellen Sie Initial Memory Pool auf 1024 (optional).
Set Maximale Speicher-Pool auf 1024 (optional).
Klicken Sie auf OK.
Starten Sie den Tomcat-Dienst.

Perm gen Raum Fehler treten aufgrund großen Raum zu verwenden, anstatt Raum Jvm vorgesehen, um den Code ausgeführt wird. Die beste Lösung für dieses Problem in UNIX-Betriebssystemen ist eine Konfiguration auf bash-Datei zu ändern. Folgende Schritte das Problem zu lösen.

Ausführen-Befehl gedit .bashrc auf Terminal.

Erstellen JAVA_OTPS Variable mit folgendem Wert:

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

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

Ich hoffe, dass dieser Ansatz auf Ihrem Problem umgehen. Wenn Sie eine Java-Version niedriger als 8 dieses Problem verwenden tritt manchmal. Aber wenn Sie verwenden Java 8 tritt das Problem nie.

Eine Erhöhung Permanent Generation Größe oder GC-Parameter zwicken wird nicht helfen, wenn Sie einen echten Speicherverlust haben. Wenn Ihre Anwendung oder einig 3rd-Party-Bibliothek nutzt, Klassenlader die einzige wirkliche und dauerhafte Lecks Lösung ist dieses Leck zu finden und zu beheben. Es gibt eine Reihe von Tools, die Ihnen helfen können, eine der letzten ist Plumbr , die gerade eine neue Version mit der erforderlichen veröffentlicht Fähigkeiten.

Auch wenn Sie log4j in Ihrem webapp verwenden, lesen Sie in diesem Absatz in log4j Dokumentation .

Es scheint, dass, wenn Sie PropertyConfigurator.configureAndWatch("log4j.properties") verwenden, können Sie verursachen Speicherlecks, wenn Sie Ihre Webapp deimplementieren.

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

Set -XX:PermSize=64m -XX:MaxPermSize=128m. Später Sie können auch versuchen MaxPermSize erhöhen. Hoffe, es wird funktionieren. Das gleiche funktioniert für mich. Einstellung nur MaxPermSize nicht für mich gearbeitet.

Ich habe versucht, mehrere Antworten und das einzige, was, was schließlich den Job tat, war diese Konfiguration für die 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>

Hoffnung dieses hilft.

jrockit getaggt dies auch für mich gelöst; aber ich, dass die Servlet-Neustart mal bemerkte, waren viel schlimmer, also, während es besser war, in der Produktion, es war irgendwie ein drag in der Entwicklung.

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

Was machst du?

Was ist die Menge der Transaktionen Präzession?

Wie viele Daten werden geladen Sie?

etc.

etc

Wahrscheinlich könnten Sie Ihre App-Profil und beginnen, einige Module aus Ihrer App aufzuräumen.

Offenbar kann dies auftreten, nachdem eine Anwendung ein paar Mal Umschichtung

Tomcat hat Hot Deploy aber es verbraucht Speicher. Versuchen Sie, Ihre Behälter hin und wieder neu gestartet wird. Auch müssen Sie die Größe des Speichers wissen mußte im Produktionsmodus laufen, dies scheint eine gute Zeit für die Forschung.

Sie sagen, dass die letzte Umdrehung von Tomcat (6.0.28 oder 6.0.29) übernimmt die Aufgabe der Umschichtung Servlets viel besser.

Ich laufe in genau das gleiche Problem, aber leider keine der vorgeschlagenen Lösungen für mich wirklich funktioniert. Das Problem nicht während des Einsatzes geschehen, und ich war mit heißen Installationen weder zu tun.

In meinem Fall trat das Problem jedes Mal an der gleichen Stelle während der Ausführung meiner Web-Anwendung, während (via Hibernate) Verbindung zur Datenbank.

Dieser Link (auch früher erwähnt) genug Innen tat liefern, das Problem zu lösen. Das Verschieben der JDBC (mysql) -Treiber aus dem WEB-INF und in dem jre / lib / ext / Ordner scheint das Problem gelöst zu haben. Dies ist nicht die ideale Lösung, da JRE auf einen neueren Aktualisierung müßten Sie den Treiber neu zu installieren. Ein weiterer Kandidat, die ähnliche Probleme verursachen könnte, ist log4j, so möchten Sie vielleicht, dass man bewegen und

Der erste Schritt in einem solchen Fall ist zu prüfen, ob die GC-Klassen von PermGen entladen darf. Der Standard-JVM ist eher konservativ in dieser Hinsicht - Klassen sind geboren, ewig zu leben. Also einmal geladen, bleiben Klassen im Speicher, auch wenn kein Code sie nicht mehr verwendet. Dies kann zu einem Problem werden, wenn die Anwendung viele Klassen dynamisch erstellt und die generierten Klassen sind nicht für einen längeren Zeitraum benötigt wird. In einem solchen Fall, so dass die JVM Klassendefinitionen entladen kann hilfreich sein. Dies kann durch Hinzufügen nur einen Konfigurationsparameter auf Ihre Startskripts erreicht werden:

-XX:+CMSClassUnloadingEnabled

Standardmäßig ist dieser auf false gesetzt und so das Sie explizit aktivieren müssen, um in Java-Optionen die folgende Option eingestellt. Wenn Sie CMSClassUnloadingEnabled aktivieren, wird GC PermGen fegen und Klassen entfernen, die nicht mehr verwendet werden. Beachten Sie, dass diese Option nur funktionieren, wenn UseConcMarkSweepGC auch mit Hilfe der unten Option aktiviert ist. Also, wenn ParallelGC läuft oder, Gott bewahre, Serial-GC, stellen Sie sicher, dass Ihre GC CMS durch Angabe gesetzt haben:

-XX:+UseConcMarkSweepGC

Zuweisen von Tomcat mehr Speicher ist nicht die richtige Lösung.

Die richtige Lösung ist, eine Bereinigung zu tun, nachdem der Kontext zerstört und neu erstellt (das heiße deploy). Die Lösung besteht darin, die Speicherlecks zu stoppen.

Wenn Ihr Tomcat / Webapp Server sagt Ihnen, dass nicht Treiber (JDBC) deregistrieren, sie dann deregistrieren. Dadurch werden die Speicherlecks zu stoppen.

Sie können eine ServletContextListener erstellen und es in Ihrem web.xml konfigurieren. Hier ist ein Beispiel 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 Sie es in Ihrem web.xml konfigurieren:

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

„Sie“ sind falsch, weil ich 6.0.29 renne und haben das gleiche Problem auch nach dem alle Optionen einstellen. Als Tim Howland oben gesagt, stellen diese Optionen nur das Unvermeidliche ab. Sie erlauben mir 3 mal umschichten, bevor der Fehler nicht bei jeder Kollision ich erneut bereitstellen.

Falls Sie bekommen dies in der Eclipse-IDE, auch nach der Einstellung der Parameter --launcher.XXMaxPermSize, -XX:MaxPermSize, etc., immer noch, wenn Sie die gleiche Fehlermeldung erhalten, ist es sehr wahrscheinlich ist, dass die Eklipse eine fehlerhafte Version von JRE verwendet, die von einigen Anwendungen von Drittanbietern installiert worden wären, und auf Standard gesetzt. Diese Buggy Versionen holen nicht die PermSize Parameter und so, egal, was Sie setzen, halten Sie immer noch diese Speicherfehler bekommen. Also, in Ihrem eclipse.ini fügen Sie die folgenden Parameter:

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

Auch stellen Sie sicher, dass der Standard-JRE in den Einstellungen in der Finsternis auf die korrekte Version von Java eingestellt.

Der einzige Weg, die für mich gearbeitet wurde mit der JRockit JVM. Ich habe MyEclipse 8.6.

Die Heap speichert JVM alle Objekte, die von einem laufenden Java-Programm. Java verwendet die new Operator-Objekte zu erstellen, und Speicher für neue Objekte auf dem Heap zur Laufzeit zugeordnet. Garbage Collection ist der Mechanismus, der automatisch den Speicher durch die Objekte enthalten Freisetzung, die nicht mehr durch das Programm verwiesen wird.

Ich habe ähnliches Problem. Meins ist JDK 7 + Maven 3.0.2 + Struts 2.0 + Google Guice Dependency Injection basiertes Projekt.

Jedes Mal, wenn ich versuchte, läuft mvn clean package Befehl, wurde es zeigt folgende Fehler und "BUILD FAILURE" ist aufgetreten

org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; verschachtelte Ausnahme ist java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException Verursacht durch: java.lang.OutOfMemoryError: PermGen Raum

Ich habe versucht, alle oben genannten nützliche Tipps und Tricks, aber leider keine für mich gearbeitet. Was für mich gearbeitet Schritt für Schritt beschrieben unter: =>

Gehen Sie zu Ihrem pom.xml
Suchen Sie nach <artifactId>maven-surefire-plugin</artifactId>
ein neues <configuration> Element hinzufügen und dann Unterelement <argLine>, in der -Xmx512m -XX:MaxPermSize=256m passieren, wie unten = gezeigt>

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

Hoffe, es hilft, glücklich Programmierung:)

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow