Radzenie sobie z " Javą.lang.OutOfMemoryError: PermGen space " błąd

You better try -XX:MaxPermSize=128M zamiast -XX:MaxPermGen=128M.

Nie mogę dokładnie określić wykorzystania tej puli pamięci, ale ma to związek z liczbą klas załadowanych do JVM. (W ten sposób włączenie rozładunku klasy dla tomcat może rozwiązać problem.) Jeśli Twoje aplikacje generują i kompilują klasy podczas uruchamiania, bardziej prawdopodobne jest, że będziesz potrzebować puli pamięci większej niż domyślna.

Błędy PermGen serwera aplikacji, które zdarzają się po wielu wdrożeniach, są najprawdopodobniej spowodowane referencjami przechowywanymi przez kontener w classloaderach starych aplikacji. Na przykład użycie niestandardowej klasy poziomu dziennika spowoduje, że odwołania będą przechowywane przez classloader serwera aplikacji. Te wycieki międzyklasowe można wykryć za pomocą nowoczesnych (JDK6+) narzędzi do analizy JVM, takich jak jmap i jhat, aby sprawdzić, które klasy nadal są przechowywane w aplikacji i przeprojektować lub wyeliminować ich użycie. Zwykle podejrzanymi są bazy danych, rejestratory i inne biblioteki poziomu bazowego.

Zobacz Classloader leaks: the dreaded " java.lang.OutOfMemoryError: PermGen space " wyjątek , a zwłaszcza jego followup post.

Często popełniane błędy to myślenie, że przestrzeń sterty i przestrzeń permgen są takie same, co wcale nie jest prawdą. Możesz mieć dużo miejsca w stercie, ale nadal może zabraknąć pamięci w permgen.

Najczęstszymi przyczynami OutofMemory w PermGen jest ClassLoader. Za każdym razem, gdy klasa jest ładowana do JVM, wszystkie jej metadane, wraz z Classloaderem, są przechowywane na obszarze PermGen i będą zbierane, gdy Classloader, który je załadował, będzie gotowy do zbierania śmieci. W Przypadku Classloader ma wyciek pamięci, ponieważ wszystkie ładowane przez niego klasy pozostaną w pamięci i spowodują OutOfMemory permGen po kilkukrotnym powtórzeniu. Klasycznym przykładem jest Java.lang.OutOfMemoryError: PermGen Space in Tomcat .

Teraz są dwa sposoby rozwiązania tego problemu:
1. Znajdź przyczynę wycieku pamięci lub jeśli występuje wyciek pamięci.
2. Zwiększ rozmiar przestrzeni PermGen używając JVM param -XX:MaxPermSize i -XX:PermSize.

Możesz również sprawdzić 2 roztwór Java.lang.OutOfMemoryError w języku Java, aby uzyskać więcej szczegółów.

Użyj parametru linii poleceń -XX:MaxPermSize=128m dla Sun JVM (oczywiście podstawiając 128 dla dowolnego rozmiaru).

Try -XX:MaxPermSize=256m and if it persists, try -XX:MaxPermSize=512m

I dodał -XX: MaxPermSize = 128m (możesz poeksperymentować co działa najlepiej) do argumentów VM jak używam Eclipse ide. W większości JVM, domyślny rozmiar PermSize wynosi około 64MB, który kończy się w pamięci, jeśli w projekcie jest zbyt wiele klas lub ogromna liczba łańcuchów.

Dla eclipse, jest to również opisane w odpowiedź .

Krok 1 : Kliknij dwukrotnie serwer tomcat w zakładce Servers

Krok 2 : Otwórz launch Conf i dodaj -XX: MaxPermSize = 128m do końca istniejących argumentów VM .

I 've been butting my head against this problem while deploying and unploying a complex web application too, and thought I' d add an explanation and my solution.

Kiedy wdrażam aplikację na Apache Tomcat, tworzony jest nowy ClassLoader dla tej aplikacji. ClassLoader jest następnie używany do załadowania wszystkich klas aplikacji, a na undeploy wszystko powinno zniknąć ładnie. Jednak w rzeczywistości nie jest to takie proste.

Jedna lub więcej klas utworzonych podczas życie aplikacji internetowej zawiera statyczne odniesienie, które gdzieś wzdłuż linii odwołuje się do Classloadera. Ponieważ odniesienie jest pierwotnie statyczne, żadna ilość śmieci nie wyczyści tego odniesienia - ClassLoader i wszystkie załadowane klasy zostaną tutaj.

I po kilku przesunięciach napotykamy OutOfMemoryError.

Więc zamiast tego stworzyłem rozwiązanie w kodzie, które działa na Apache Tomcat 6.0. Nie testowałem na żadnym innym serwerze aplikacji i muszę podkreślić, że jest to bardzo prawdopodobne, że nie zadziała bez modyfikacji na żadnym innym serwerze aplikacji.

Chciałbym również powiedzieć, że osobiście nienawidzę tego kodu, i że nikt nie powinien używać tego jako "szybkiej poprawki", jeśli istniejący kod można zmienić, aby użyć odpowiednich metod shutdown i cleanup . Jedyne, co powinno być użyte, To jeśli istnieje zewnętrzna biblioteka, od której zależy Twój kod (w moim przypadku był to klient RADIUS), która nie zapewnia środków do czyszczenia własnych statycznych odniesień.

//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();

Alternatywnie możesz przełączyć się na JRockit, który obsługuje permgen inaczej niż Sun JVM. Ogólnie ma również lepszą wydajność.

Http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

1) zwiększenie rozmiaru pamięci PermGen

Pierwszą rzeczą, jaką można zrobić, jest zwiększenie rozmiaru stałej przestrzeni sterty generacji. Nie można tego zrobić za pomocą zwykłych argumentów JVM –Xms(set initial heap size) i –Xmx(set maximum heap size), ponieważ, jak wspomniano, stała przestrzeń sterty generowania jest całkowicie oddzielona od zwykłej przestrzeni sterty Javy, i te argumenty ustawiają przestrzeń dla tej zwykłej przestrzeni sterty Javy. Istnieją jednak podobne argumenty, które można wykorzystać (w najmniej z Sun/OpenJDK jvms), aby powiększyć rozmiar sterty permanentnej generacji:

 -XX:MaxPermSize=128m

Domyślnie jest 64m.

2) Włącz Zamiatanie

Innym sposobem, aby zadbać o to na dobre, jest umożliwienie rozładowania klas, aby Twój PermGen nigdy się nie wyczerpał: {]}

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Możesz znaleźć szczegóły tego błędu.

Http://faisalbhagat.blogspot.com/2014/09/java-outofmemoryerror-permgen.html

Miałem problem, o którym tu mówimy, mój scenariusz to eclipse-helios + tomcat + jsf i to, co robiłeś, to wdrażanie prostej aplikacji do tomcat. Pokazywałem ten sam problem tutaj, rozwiązałem go w następujący sposób.

W eclipse przejdź do zakładki servers Kliknij dwukrotnie na zarejestrowanym serwerze w moim przypadku tomcat 7.0, otworzy się mój serwer plików Ogólne informacje o rejestracji. W sekcji "Informacje ogólne" Kliknij na link " Otwórz uruchomienie konfiguracja " , otwiera wykonanie opcji serwera w zakładce argumenty w argumentach VM dodanych na końcu tych dwóch wpisów

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

Najprostszą odpowiedzią w dzisiejszych czasach jest użycie Java 8.

Nie rezerwuje już pamięci wyłącznie dla przestrzeni PermGen, pozwalając pamięci PermGen współdzielić się ze zwykłą pulą pamięci.

Pamiętaj, że będziesz musiał usunąć wszystkie niestandardowe parametry startowe -XXPermGen...=... JVM, jeśli nie chcesz, aby Java 8 narzekała, że nic nie robią.

Komunikat java.lang.OutOfMemoryError: PermGen spacja wskazuje, że stały obszar generacji w pamięci jest wyczerpany.

Wszelkie aplikacje Java mogą używać ograniczonej ilości pamięci. Dokładna ilość pamięci, z której może korzystać dana aplikacja, jest określona podczas uruchamiania aplikacji.

Pamięć Java jest rozdzielona na różne regiony, co widać na poniższym obrazku:

Metaspace: nowa przestrzeń pamięci jest born

Dobrą wiadomością jest to, że oznacza to koniec problemów z przestrzenią java.lang.OutOfMemoryError: PermGen i brak potrzeby dostrajania i monitorowania tej przestrzeni pamięci za pomocą Java_8_Download lub wyższej.

1. Otwórz tomcat7w z katalogu Bin Tomcat lub wpisz Monitor Tomcat w menu start (otwiera się okno z zakładkami z różnymi informacjami o usłudze).

2. W obszarze opcji Javy dodaj tę linię:

   -XX:MaxPermSize=128m
   

3. Ustaw początkową pulę pamięci na 1024 (opcjonalnie).
4. Ustaw maksymalną pulę pamięci na 1024 (opcjonalnie).
5. Kliknij Ok.
Uruchom ponownie usługę Tomcat.

Błąd przestrzeni gen Perm występuje z powodu użycia dużej przestrzeni, a nie JVM pod warunkiem miejsca do wykonania kodu. Najlepszym rozwiązaniem tego problemu w systemach operacyjnych UNIX jest zmiana konfiguracji w pliku bash. Następujące kroki rozwiązać problem.

Uruchom polecenie {[1] } na terminalu.

Utwórz zmienną JAVA_OTPS o następującej wartości:

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

Zapisz plik bash. Uruchom polecenie Exec bash na terminalu. Uruchom ponownie serwer.

Mam nadzieję, że takie podejście zadziała na Twoim problem. Jeśli używasz wersji Java niższej niż 8, czasami występuje ten problem. Ale jeśli używasz Java 8 problem nigdy nie występuje.

Zwiększenie trwałego rozmiaru generacji lub dostosowanie parametrów GC nie pomoże, jeśli masz prawdziwy wyciek pamięci. Jeśli Twoja aplikacja lub jakaś biblioteka innej firmy używa, Ładowarki klasy leaks jedynym prawdziwym i stałym rozwiązaniem jest znalezienie tego wycieku i naprawienie go. Istnieje wiele narzędzi, które mogą Ci pomóc, jednym z ostatnich jest Plumbr , który właśnie wydał nową wersję z wymaganymi możliwościami.

Również jeśli używasz log4j w swojej aplikacji internetowej, sprawdź ten akapit w log4j Dokumentacja .

Wydaje się, że jeśli używasz PropertyConfigurator.configureAndWatch("log4j.properties"), można spowodować wycieki pamięci, gdy undeploy webapp.

Mam kombinację Hibernate+Eclipse RCP, próbowałem używać -XX:MaxPermSize=512m i -XX:PermSize=512m i wydaje mi się, że działa.

Set -XX:PermSize=64m -XX:MaxPermSize=128m. Później możesz również spróbować zwiększyć MaxPermSize. Mam nadzieję, że się uda. To samo działa u mnie. Ustawienie tylko MaxPermSize nie zadziałało.

Próbowałem kilku odpowiedzi i jedyną rzeczą, która w końcu zrobiła to zadanie, była konfiguracja wtyczki kompilatora w 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>

Jrockit rozwiązał to również dla mnie; jednak zauważyłem, że czasy restartu servleta były znacznie gorsze, więc chociaż był lepszy w produkcji, był to rodzaj przeciągnięcia w rozwoju.

Konfiguracja pamięci zależy od charakteru aplikacji.

Co robisz?

Jaka jest ilość transakcji?

Ile danych ładujesz?

Itd.

Itd.

Etc

Prawdopodobnie możesz profilować swoją aplikację i zacząć czyścić niektóre moduły z aplikacji.

widocznie może to nastąpić po kilkukrotnym przesunięciu aplikacji

Tomcat ma hot deploy ale to zużywa pamięć. Spróbuj raz na jakiś czas ponownie uruchomić kontener. Musisz również znać ilość pamięci potrzebnej do uruchomienia w trybie produkcyjnym, wydaje się to dobrym momentem na te badania.

Mówią, że najnowsza wersja Tomcata (6.0.28 lub 6.0.29) radzi sobie z zadaniem przenoszenia serwletów znacznie lepiej.

Napotkałem dokładnie ten sam problem, ale niestety żadne z proponowanych rozwiązań nie zadziałało na mnie. Problem nie wystąpił podczas wdrażania, a ja nie robiłem żadnych gorących wdrożeń.

W moim przypadku problem występował za każdym razem w tym samym momencie podczas wykonywania mojej aplikacji webowej, podczas łączenia się (poprzez hibernate) z bazą danych.

Ten link (również wspomniany wcześniej) dostarczył wystarczająco dużo wnętrzności, aby rozwiązać problem. Moving the jdbc - (mysql)-driver z WEB-INF i do folderu jre/lib/ext/ wydaje się rozwiązał problem. Nie jest to idealne rozwiązanie, ponieważ aktualizacja do nowszego JRE wymagałaby ponownej instalacji sterownika. Innym kandydatem, który może powodować podobne problemy, jest log4j, więc możesz również przenieść ten jeden

Pierwszym krokiem w takim przypadku jest sprawdzenie, czy GC może rozładowywać klasy z PermGen. Standard JVM jest pod tym względem dość konserwatywny – klasy rodzą się, by żyć wiecznie. Tak więc po załadowaniu klasy pozostają w pamięci, nawet jeśli żaden kod ich nie używa. Może to stać się problemem, gdy aplikacja tworzy wiele klas dynamicznie i generowane klasy nie są potrzebne przez dłuższy czas. W takim przypadku pomocne może być Zezwolenie JVM na rozładowanie definicji klas. To można to osiągnąć dodając tylko jeden parametr konfiguracyjny do skryptów startowych:

-XX:+CMSClassUnloadingEnabled

Domyślnie jest to ustawione na false, więc aby to włączyć, musisz jawnie ustawić następującą opcję w opcjach Java. Jeśli włączysz CMSClassUnloadingEnabled, GC również usunie PermGen i usunie klasy, które nie są już używane. Należy pamiętać, że ta opcja będzie działać tylko wtedy, gdy useconcmarksweepgc jest również włączony przy użyciu poniższej opcji. Więc przy uruchomieniu ParallelGC lub, broń Boże, seryjny GC, upewnij się, że ustawiłeś GC na CMS, podając:

-XX:+UseConcMarkSweepGC

Przypisanie Tomcatowi większej ilości pamięci nie jest właściwym rozwiązaniem.

Poprawnym rozwiązaniem jest czyszczenie po zniszczeniu i odtworzeniu kontekstu (hot deploy). Rozwiązaniem jest zatrzymanie wycieków pamięci.

Jeśli Twój serwer Tomcat / Webapp informuje, że nie udało się wyrejestrować sterowników( JDBC), Wyrejestruj je. To zatrzyma wycieki pamięci.

Możesz utworzyć ServletContextListener i skonfigurować go w swojej sieci.xml. Oto przykład 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();
        }        
    }
}

I tutaj konfigurujesz go w swojej sieci.xml:

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

" oni " są w błędzie, ponieważ mam 6.0.29 i mam ten sam problem nawet po ustawieniu wszystkich opcji. Jak powiedział Tim Howland powyżej, te opcje odkładają tylko nieuniknione. Pozwalają mi przegrupować 3 razy przed uderzeniem błędu zamiast za każdym razem, gdy przegrupowuję.

W przypadku gdy dostajesz to w Eclipse IDE, nawet po ustawieniu parametrów --launcher.XXMaxPermSize, -XX:MaxPermSize, etc, nadal jeśli dostajesz ten sam błąd, najprawdopodobniej jest to, że eclipse używa błędnej wersji JRE, która byłaby zainstalowana przez niektóre aplikacje innych firm i ustawiona na domyślną. Te wadliwe wersje nie odbierają parametrów PermSize, więc bez względu na to, co ustawisz, nadal otrzymujesz te błędy pamięci. Więc, w Twoim zaćmieniu.ini dodaje następujące parametry:

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

Upewnij się również, że ustawiłeś domyślne JRE w preferencjach w eclipse na poprawną wersję Javy.

Jedyny sposób, który zadziałał dla mnie był z JRockit JVM. Mam moje 8.6.

Sterta JVM przechowuje wszystkie obiekty generowane przez uruchomiony program Java. Java używa operatora new do tworzenia obiektów, a pamięć dla nowych obiektów jest przydzielana na stercie w czasie wykonywania. Garbage collection jest mechanizmem automatycznego zwalniania pamięci zawartej w obiektach, do których program nie odwołuje się.

Miałem podobny problem. Mój to JDK 7 + Maven 3.0.2 + Struts 2.0 + Google Guice dependency injection based project.

Ilekroć próbowałem biegać mvn clean package polecenie, pokazywało następujący błąd i wystąpiło "Build FAILURE"

Org.Apacz.maven.na pewno.util.SurefireReflectionException: java.lang.zastanów się.InvocationTargetException; zagnieżdżonym wyjątkiem jest java.lang.zastanów się.InvocationTargetException: null java.lang.zastanów się.InvocationTargetException Spowodowane przez: java.lang.OutOfMemoryError: PermGen space

Próbowałem wszystkich powyższych przydatnych wskazówek i trików, ale niestety żadna nie zadziałała. To, co u mnie działało, opisane jest krok po kroku poniżej: =>

1. idź do swojego pom.xml
2. Szukaj <artifactId>maven-surefire-plugin</artifactId>
3. Dodaj nowy <configuration> element, a następnie <argLine> element podrzędny, w którym pass -Xmx512m -XX:MaxPermSize=256m Jak pokazano poniżej = >

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

Nadzieja pomaga, miłego programowania:)