Jak radzić sobie z " java.lang.OutOfMemoryError: błąd Java heap space" (rozmiar stosu 64 MB)

Uruchom Javę z opcją wiersza poleceń -Xmx, która ustawia maksymalny rozmiar sterty.

Szczegóły znajdziesz tutaj..

Możesz określić dla każdego projektu, ile miejsca na stercie potrzebuje twój projekt

Poniżej znajduje się zaćmienie Heliosa / Juno / Keplera:

Prawy przycisk myszy na

 Run As - Run Configuration - Arguments - Vm Arguments, 

Następnie dodaj to

-Xmx2048m

Zwiększenie rozmiaru stosu nie jest "naprawą", jest "tynkiem", w 100% tymczasowym. Znowu rozbije się gdzieś indziej. Aby uniknąć tych problemów, napisz Kod o wysokiej wydajności.

1. używaj zmiennych lokalnych tam, gdzie to możliwe.
2. Upewnij się, że wybrałeś właściwy obiekt (np. wybór pomiędzy String, StringBuffer i StringBuilder)
3. Użyj dobrego systemu kodu dla swojego programu (np. używając zmiennych statycznych VS zmiennych niestatycznych)
4. inne rzeczy, które mogą działać na Twoim kod.
5. spróbuj poruszać się z multy THREADING

Wielkie zastrzeżenie - - - - w moim biurze stwierdziliśmy, że (na niektórych maszynach z windows) nie możemy przeznaczyć więcej niż 512m dla Java heap. Okazało się, że jest to spowodowane zainstalowanym na niektórych z tych komputerów produktem Kaspersky anti-virus. Po odinstalowaniu tego produktu AV okazało się, że możemy przeznaczyć co najmniej 1.6 gb, czyli-Xmx1600m (M jest obowiązkowe inne mądre doprowadzi to do kolejnego błędu "zbyt mała początkowa kupa") działa.

Nie mam pojęcia, czy tak się dzieje z innymi produktami AV, ale prawdopodobnie dzieje się tak, ponieważ program AV rezerwuje mały blok pamięci w każdej przestrzeni adresowej, zapobiegając tym samym jednemu naprawdę dużemu przydziale.

Argument VM zadziałał dla mnie w eclipse. Jeśli używasz eclipse w wersji 3.4, wykonaj następujące czynności

Przejdź do Run --> Run Configurations --> następnie wybierz projekt pod Maven build -- > następnie wybierz zakładkę " JRE " -- > następnie wprowadź -Xmx1024m.

Alternatywnie możesz zrobić Run --> Run Configurations --> select the "JRE" tab --> następnie wpisać - Xmx1024m

Powinno to zwiększyć ilość pamięci dla wszystkich buildów/projektów. Powyższy rozmiar pamięci to 1 GB. Możesz zoptymalizować sposób, w jaki chcesz.

Tak, za pomocą-Xmx możesz skonfigurować dla siebie więcej pamięci JVM. Aby mieć pewność, że nie wyciekasz ani nie marnujesz pamięci. Zrób zrzut sterty i użyj analizatora pamięci Eclipse do analizy zużycia pamięci.

Chciałbym dodać rekomendacje z oracle trouble shooting Artykuł

Wyjątek w wątku thread_name: java.lang.OutOfMemoryError: Java heap space

Komunikat szczegółowy Java heap space wskazuje, że obiekt nie może zostać przydzielony do Java heap. Ten błąd nie musi oznaczać wycieku pamięci

możliwe przyczyny:

1. prosty problem z konfiguracją , gdzie określony rozmiar sterty jest niewystarczająca do zastosowania.

2. Aplikacja nieumyślnie przechowuje odwołania do obiektów , co zapobiega ich zbieraniu.

3. nadmierne stosowanie finalizatorów .

Inne potencjalne źródło tego błędu pojawia się w aplikacjach, które nadmiernie wykorzystują finalizery. Jeśli klasa ma metodę finalize, to obiekty tego typu nie mają odzyskiwanej przestrzeni na śmieci czas zbierania

Po garbage collection obiekty są w kolejce do finalizacji , co następuje w późniejszym czasie. finalizery są uruchamiane przez wątek demona obsługujący kolejkę finalizacji. Jeśli wątek finalizer nie nadąża za kolejką finalizacji, to sterta Javy może się wypełnić i ten typ wyjątku OutOfMemoryError zostanie wyrzucony.

Jednym ze scenariuszy, który może spowodować taką sytuację jest aplikacja tworzy wątki o wysokim priorytecie, które powodują wzrost kolejki finalizacji w tempie szybszym niż tempo, z jakim wątek finalizatora obsługuje tę kolejkę.

Wykonaj poniższe kroki:

1. Open catalina.sh z tomcat / bin.

2. Chnage JAVA_OPTS to

   JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1536m 
   -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m 
   -XX:MaxPermSize=256m -XX:+DisableExplicitGC"
   

3. Uruchom ponownie tomcat

Czytałem gdzie indziej, że można spróbować-złapać Javę.lang.OutOfMemoryError i na bloku catch, możesz uwolnić wszystkie zasoby, które wiesz, że mogą używać dużo pamięci, bliskie połączenia i tak dalej, a następnie zrobić System.gc () następnie spróbuj ponownie cokolwiek zamierzałeś zrobić.

Inny sposób jest taki, chociaż Nie wiem, czy to zadziała, ale obecnie testuję, czy zadziała na mojej aplikacji.

Chodzi o to, aby usuwać śmieci przez wywołanie systemu.gc (), który jest znany z zwiększania wolnej pamięci. Możesz to sprawdzać po wykonaniu kodu pożerającego pamięć.

//Mimimum acceptable free memory you think your app needs
long minRunningMemory = (1024*1024);

Runtime runtime = Runtime.getRuntime();

if(runtime.freeMemory()<minRunningMemory)
 System.gc();

Miałem do czynienia z tym samym problemem java heap size. Mam dwa rozwiązania jeśli używasz java 5 (1.5).

1st: - po prostu zainstaluj jdk1. 6 i przejdź do preferencji eclipse i ustaw ścieżkę jre jav1 1.6 tak jak zainstalowałeś.

2nd: - Sprawdź argument VM i niech będzie cokolwiek to jest. wystarczy dodać jeden wiersz poniżej wszystkich argumentów obecnych w argumentach VM jako -Xms512m-Xmx512m-XX: MaxPermSize=...m (192m).

Myślę, że zadziała...

Łatwym sposobem rozwiązania OutOfMemoryError w Javie jest zwiększenie maksymalnego rozmiaru sterty za pomocą opcji JVM -Xmx512M, to natychmiast rozwiąże Twój OutOfMemoryError. Jest to moje preferowane rozwiązanie, gdy wydostaję się OutOfMemoryError w Eclipse, Maven lub ANT podczas budowania projektu, ponieważ na podstawie rozmiaru projektu można łatwo zabrakło pamięci.

Oto przykład zwiększenia maksymalnego rozmiaru sterty JVM, również lepiej zachować-Xmx do-Xms rację 1: 1 lub 1: 1.5 jeśli ustawiasz rozmiar sterty w Twoja aplikacja java.

export JVM_ARGS="-Xms1024m -Xmx1024m"

Link Referencyjny

Jeśli chcesz monitorować zużycie pamięci w czasie wykonywania, java.lang.pakiet zarządzania oferuje Mbeany, które mogą być używane do monitorowania pul pamięci w maszynie wirtualnej (np. eden space, tenured generation itp.), a także zachowanie usuwania śmieci.

Wolna przestrzeń sterty zgłaszana przez te Mbeany będzie się znacznie różnić w zależności od zachowania GC, szczególnie jeśli aplikacja generuje wiele obiektów, które są później GC-ed. Jednym z możliwych sposobów jest monitorowanie wolnej przestrzeni sterty po każdym full-GC, którego możesz użyć do podjęcia decyzji o zwolnieniu pamięci przez utrzymywanie obiektów.

Ostatecznie najlepszym rozwiązaniem jest ograniczenie retencji pamięci tak dalece, jak to możliwe, podczas gdy wydajność pozostaje akceptowalna. Jak wspomniano w poprzednim komentarzu, pamięć jest zawsze ograniczona, ale Twoja aplikacja powinna mieć strategię radzenia sobie z wyczerpaniem pamięci.

Zauważ, że jeśli potrzebujesz tego w sytuacji wdrożenia, rozważ użycie Java WebStart (z wersją "ondisk", a nie sieciową - możliwe w Javie 6u10 i nowszych), ponieważ pozwala na podanie różnych argumentów do JVM w sposób wieloplatformowy.

W przeciwnym razie będziesz potrzebował programu uruchamiającego specyficznego dla systemu operacyjnego, który ustawia potrzebne argumenty.

Domyślnie dla rozwoju JVM używa małych rozmiarów i małych konfiguracji dla innych funkcji związanych z wydajnością. Ale do produkcji można dostrajać np. (dodatkowo może istnieć konfiguracja serwera aplikacji) - > (Jeśli nadal nie ma wystarczającej ilości pamięci, aby spełnić żądanie, A sterta osiągnęła już maksymalny rozmiar, wystąpi OutOfMemoryError)

-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size

-XX:ParallelGCThreads=8
-XX:+CMSClassUnloadingEnabled
-XX:InitiatingHeapOccupancyPercent=70
-XX:+UnlockDiagnosticVMOptions
-XX:+UseConcMarkSweepGC
-Xms512m
-Xmx8192m
-XX:MaxPermSize=256m (in java 8 optional)

Na przykład: na platformie linux dla trybu produkcyjnego preferowane ustawienia.

Po pobraniu i skonfigurowaniu serwer z tą drogą http://www.ehowstuff.com/how-to-install-and-setup-apache-tomcat-8-on-centos-7-1-rhel-7/

1.Utwórz setenv.sh plik w folderze / opt / tomcat / bin /

   touch /opt/tomcat/bin/setenv.sh

2.Otwórz i napisz ten params dla ustawienia preferowanego trybu.

nano  /opt/tomcat/bin/setenv.sh 

export CATALINA_OPTS="$CATALINA_OPTS -XX:ParallelGCThreads=8"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+CMSClassUnloadingEnabled"
export CATALINA_OPTS="$CATALINA_OPTS -XX:InitiatingHeapOccupancyPercent=70"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UnlockDiagnosticVMOptions"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseConcMarkSweepGC"
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxMetaspaceSize=256M"

3.service tomcat restart

Zauważ, że JVM używa więcej pamięci niż tylko sterty. Na przykład Metody Java, stosy wątków i natywne uchwyty są przydzielane w pamięci oddzielony od sterty, a także JVM wewnętrzny struktury danych.

Jeśli nadal przydzielasz i przechowujesz odwołania do obiektu, zapełnisz dowolną ilość pamięci, jaką posiadasz.

Jedną z opcji jest zamknięcie i otwarcie przezroczystego pliku podczas przełączania kart (zachowujesz tylko wskaźnik do pliku, a gdy użytkownik przełącza kartę, zamykasz i czyścisz wszystkie obiekty... to spowolni zmianę Pliku... ale...), a może zachować tylko 3 lub 4 pliki w pamięci.

Inną rzeczą, którą powinieneś zrobić, jest to, że gdy użytkownik otworzy plik, załaduj go i przechwyć dowolny OutOfMemoryError, następnie (ponieważ nie można otworzyć pliku) zamknąć ten plik, wyczyścić jego obiekty i ostrzec użytkownika, że powinien zamknąć nieużywane pliki.

Twój pomysł dynamicznego rozszerzania pamięci wirtualnej nie rozwiązuje problemu, ponieważ maszyna ma ograniczone zasoby, więc powinieneś zachować ostrożność i rozwiązywać problemy z pamięcią (lub przynajmniej być ostrożnym z nimi).

Kilka wskazówek, które widziałem z wyciekami pamięci to:

--> pamiętaj, że jeśli umieścisz coś w zbiorze a potem zapomnij o tym, nadal masz do niego silne odniesienie, Więc anuluj kolekcję, wyczyść ją lub zrób coś z nią... jeśli nie, trudno będzie znaleźć wyciek pamięci.

-- > może, używając kolekcji ze słabymi referencjami (weakhashmap...) może pomóc w problemach z pamięcią, ale ty musisz być ostrożnym z tym, ponieważ może się okazać, że szukany obiekt został zebrany.

-- > innym pomysłem jaki znalazłem jest stworzenie trwałego zbioru, który przechowywane w obiektach bazy danych. To byłoby chyba najlepsze podejście...

Jeśli chodzi o netbeans, możesz ustawić maksymalny rozmiar sterty, aby rozwiązać problem. Najpierw przejdź do "Uruchom", a następnie -- > "Ustaw konfigurację projektu" -- > "Dostosuj" -- > "Uruchom" wyskakującego okna -- > "Opcja maszyny wirtualnej" -- > wypełnij "- Xms2048m-Xmx2048m".

Jeśli ten problem występuje w Wildfly 8 i JDK1. 8, to musimy określić ustawienia MaxMetaSpace zamiast ustawień PermGen.

Na przykład musimy dodać poniżej konfigurację w setenv.sh akta wildfly. JAVA_OPTS="$JAVA_OPTS -XX:MaxMetaspaceSize=256M"

Aby uzyskać więcej informacji, sprawdź Wildfly Heap Issue