Błąd java.lang.OutOfMemoryError: Przekroczono limit obciążenia GC

Podczas wykonywania testów JUnit pojawia się ten komunikat o błędzie:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Wiem, co to OutOfMemoryErrorjest, ale co oznacza limit napowietrzny GC? Jak mogę to rozwiązać?

Ten komunikat oznacza, że ​​z jakiegoś powodu śmieciarz zajmuje zbyt dużo czasu (domyślnie 98% całego czasu procesora w procesie) i odzyskuje bardzo mało pamięci przy każdym uruchomieniu (domyślnie 2% sterty).

Oznacza to skutecznie, że Twój program przestaje robić postępy i jest cały czas zajęty tylko wyrzucaniem elementów bezużytecznych.

JVM rzuca to, Erroraby Twoja aplikacja nie pochłaniała czasu procesora bez wykonywania czegokolwiek, dzięki czemu masz szansę zdiagnozować problem.

Rzadkie przypadki, w których to widziałem, polegały na tym, że jakiś kod tworzył mnóstwo tymczasowych obiektów i ton słabo przywoływanych obiektów w już bardzo ograniczonym pamięci.

Sprawdź przewodnik strojenia Java GC, który jest dostępny dla różnych wersji Java i zawiera sekcje dotyczące tego konkretnego problemu:

• Przewodnik po tuningu Java 11 zawiera dedykowane sekcje dotyczące nadmiernego GC dla różnych śmieciarek:
  • dla kolektora równoległego
  • dla kolektora Concurrent Mark Sweep (CMS)
  • nie ma wzmianki o tym specyficznym błędzie dla kolektora Garbage First (G1).
• Przewodnik po tuningu Java 8 i jego sekcja Nadmierna GC
• Przewodnik po tuningu Java 6 i jego sekcja Nadmierna GC .

Cytując z artykułu Oracle „Java SE 6 HotSpot [tm] Tuning czyszczenia maszyn wirtualnych” :

Nadmierny czas GC i OutOfMemoryError

Kolektor równoległy wyrzuci błąd OutOfMemoryError, jeśli zbyt dużo czasu jest poświęcane na wyrzucanie elementów bezużytecznych: jeśli więcej niż 98% całkowitego czasu jest spędzane na zbieraniu elementów bezużytecznych i odzyskane jest mniej niż 2% sterty, zostanie wyrzucony błąd OutOfMemoryError. Ta funkcja ma na celu zapobieganie uruchamianiu aplikacji przez dłuższy czas przy niewielkim lub zerowym postępie, ponieważ sterty są zbyt małe. W razie potrzeby tę funkcję można wyłączyć, dodając opcję -XX:-UseGCOverheadLimitdo wiersza polecenia.

EDYCJA: wygląda na to, że ktoś może pisać szybciej niż ja :)

Jeśli masz pewność, że w twoim programie nie ma wycieków pamięci , spróbuj:

1. Na przykład zwiększ rozmiar sterty -Xmx1g.
2. Włącz równoległy kolektor niskich przerw -XX:+UseConcMarkSweepGC.
3. Użyj ponownie istniejących obiektów, jeśli to możliwe, aby zaoszczędzić trochę pamięci.

W razie potrzeby kontrolę limitu można wyłączyć, dodając opcję -XX:-UseGCOverheadLimitdo wiersza poleceń.

Zwykle jest to kod. Oto prosty przykład:

import java.util.*;

public class GarbageCollector {

    public static void main(String... args) {

        System.out.printf("Testing...%n");
        List<Double> list = new ArrayList<Double>();
        for (int outer = 0; outer < 10000; outer++) {

            // list = new ArrayList<Double>(10000); // BAD
            // list = new ArrayList<Double>(); // WORSE
            list.clear(); // BETTER

            for (int inner = 0; inner < 10000; inner++) {
                list.add(Math.random());
            }

            if (outer % 1000 == 0) {
                System.out.printf("Outer loop at %d%n", outer);
            }

        }
        System.out.printf("Done.%n");
    }
}

Korzystanie z Java 1.6.0_24-b07 w 32-bitowym systemie Windows 7.

java -Xloggc:gc.log GarbageCollector

Następnie spójrz na gc.log

• Wywołano 444 razy przy użyciu metody BAD
• Uruchomiono 666 razy przy użyciu metody WORSE
• Wywołano 354 razy przy użyciu LEPSZEJ metody

Przyznaję, że nie jest to najlepszy test ani najlepszy projekt, ale w obliczu sytuacji, w której nie masz innego wyboru, jak zaimplementować taką pętlę lub gdy masz do czynienia z istniejącym kodem, który źle się zachowuje, wybór ponownego użycia obiektów zamiast tworzenia nowych może zmniejszyć ile razy kolektor śmieci przeszkadza ...

Przyczyna błędu według platformy Java [8], Podręcznik rozwiązywania problemów w edycji standardowej : (wyróżnienie i podział wierszy dodane)

[...] „Przekroczono limit narzutu GC” wskazuje, że moduł wyrzucający śmieci działa cały czas, a program Java robi bardzo wolne postępy.

Po wyrzucaniu elementów bezużytecznych, jeśli proces Java spędza więcej niż około 98% swojego czasu na zbieraniu elementów bezużytecznych i jeśli odzyskuje mniej niż 2% sterty i do tej pory robił ostatnie 5 (stała czasowa kompilacji) kolejnych śmieci kolekcje, a następnie java.lang.OutOfMemoryErrorwyrzuca się. [...]

1. Zwiększ rozmiar sterty, jeśli bieżąca sterty nie jest wystarczająca.
2. Jeśli nadal występuje ten błąd po zwiększeniu pamięci sterty, użyj narzędzi do profilowania pamięci , takich jak MAT (narzędzie do analizy pamięci), Visual VM itp. I napraw wycieki pamięci.
3. Zaktualizuj wersję JDK do najnowszej wersji (1.8.x) lub co najmniej 1.7.xi użyj algorytmu G1GC. . Celem przepustowości G1 GC jest 90 procent czasu aplikacji i 10 procent czasu usuwania śmieci

4. Oprócz ustawienia pamięci sterty za pomocą - Xms1g -Xmx2gspróbuj

   -XX:+UseG1GC -XX:G1HeapRegionSize=n -XX:MaxGCPauseMillis=m  
   -XX:ParallelGCThreads=n -XX:ConcGCThreads=n

Zapoznaj się z kilkoma powiązanymi pytaniami dotyczącymi G1GC

• Śmieciarka Java 7 (JDK 7) i dokumentacja na G1

• Śmieciarka Java G1 w produkcji

• Artykuł Oracle dotyczący technologii sieciowej dostrajania GC

Po prostu zwiększ nieco rozmiar sterty, ustawiając tę ​​opcję w

Uruchom → Uruchom konfiguracje → Argumenty → Argumenty VM

-Xms1024M -Xmx2048M

Xms - dla minimalnego limitu

Xmx - dla maksymalnego limitu

Dla mnie zadziałały następujące kroki:

1. Otwórz eclipse.iniplik

2. Zmiana

   -Xms40m
   -Xmx512m

   do

   -Xms512m
   -Xmx1024m

3. Uruchom ponownie Eclipse

Spójrz tutaj

Spróbuj tego

otwórz build.gradleplik

  android {
        dexOptions {
           javaMaxHeapSize = "4g"
        }
   }

Poniższe działało dla mnie. Po prostu dodaj następujący fragment kodu:

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 10
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
        multiDexEnabled true
    }
dexOptions {
        javaMaxHeapSize "4g"
    }
}

zwiększ javaMaxHeapsize w pliku build.gradle (moduł: aplikacja)

dexOptions {
    javaMaxHeapSize "1g"
}

do (Dodaj tę linię w gradiencie)

 dexOptions {
        javaMaxHeapSize "4g"
    }

Opisy rozmiarów sterty Java (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

Ustawia początkowy rozmiar sterty Java. Domyślny rozmiar to 2097152 (2 MB). Wartości muszą być wielokrotnością 1024 bajtów (1 KB) i być większe. (Flaga -server zwiększa domyślny rozmiar do 32 M.)

-Xmn size in bytes

Example : java -Xmx2m

Ustawia początkowy rozmiar sterty Java dla generacji Eden. Wartość domyślna to 640 KB. (Flaga -server zwiększa domyślny rozmiar do 2M).

-Xmx size in bytes

Example : java -Xmx2048m

Ustawia maksymalny rozmiar, do którego może wzrosnąć sterta Java. Domyślny rozmiar to 64 M. (Flaga -server zwiększa domyślny rozmiar do 128M.) Maksymalny limit sterty wynosi około 2 GB (2048 MB).

Formatowanie argumentów pamięci Java (xms, xmx, xmn)

Podczas ustawiania wielkości sterty Java należy podać argument pamięci, używając jednej z liter „m” lub „M” dla MB, lub „g” lub „G” dla GB. Twoje ustawienie nie będzie działać, jeśli podasz „MB” lub „GB”. Prawidłowe argumenty wyglądają tak:

-Xms64m lub -Xms64M -Xmx1g lub -Xmx1G Można również użyć 2048 MB, aby określić 2 GB Ponadto, należy podać liczby całkowite przy podawaniu argumentów. Użycie -Xmx512m jest prawidłową opcją, ale -Xmx0,5g spowoduje błąd.

To odniesienie może być pomocne dla kogoś.

Możesz także zwiększyć przydział pamięci i rozmiar sterty, dodając to do gradle.propertiespliku:

org.gradle.jvmargs=-Xmx2048M -XX\:MaxHeapSize\=32g

Nie musi to być 2048M i 32g, więc zmień go tak, jak chcesz.

Rozwiązany:
Wystarczy dodać
org.gradle.jvmargs=-Xmx1024m
w
gradle.properties
a jeśli nie istnieje, utwórz go.

Pracuję w Android Studio i napotkałem ten błąd podczas próby wygenerowania podpisanego pakietu APK do wydania. Byłem w stanie zbudować i przetestować APK debugowania bez problemu, ale jak tylko chciałem zbudować APK wersji, proces kompilacji będzie działał przez kilka minut, a następnie w końcu zakończy się komunikatem „Błąd java.lang.OutOfMemoryError: GC przekroczony limit napowietrzny ". Zwiększyłem rozmiary sterty zarówno dla maszyny wirtualnej, jak i kompilatora Android DEX, ale problem nadal występował. W końcu po wielu godzinach i kubkach kawy okazało się, że problem występuje w moim pliku „build.gradle” na poziomie aplikacji - miałem parametr „minifyEnabled” dla typu kompilacji wydania ustawiony na „false”, w konsekwencji uruchamiając rzeczy Proguard na temat kodu, który nie przeszedł procesu zmniejszania kodu (patrz https://developer.android.). Zmieniłem parametr „minifyEnabled” na „true”, a kompilacja wydania została wykonana jak sen :)

Krótko mówiąc, musiałem zmienić plik „build.gradle” na poziomie aplikacji z: // ...

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

do

    //...

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

Aby zwiększyć rozmiar sterty w IntelliJ IDEA, postępuj zgodnie z następującymi instrukcjami. To zadziałało dla mnie.

Dla użytkowników systemu Windows

Przejdź do lokalizacji, w której jest zainstalowane IDE i wyszukaj następujące.

idea64.exe.vmoptions

Edytuj plik i dodaj następujące elementy.

-Xms512m
-Xmx2024m
-XX:MaxPermSize=700m
-XX:ReservedCodeCacheSize=480m

To jest to !!

możesz spróbować wprowadzić zmiany w ustawieniach serwera, odwołując się do tego obrazu i zwiększyć rozmiar pamięci do przetwarzania zmian procesu podświetlonych na żółto

możesz także wprowadzić zmiany w stosie Java, otwierając cmd-> set _java_opts -Xmx2g
2g (2 gigabajty) w zależności od złożoności programu

spróbuj użyć mniej stałych zmiennych i zmiennych temp

Musisz zwiększyć rozmiar pamięci w Jdeveloper, przejdź do setDomainEnv.cmd .

set WLS_HOME=%WL_HOME%\server    
set XMS_SUN_64BIT=**256**
set XMS_SUN_32BIT=**256**
set XMX_SUN_64BIT=**3072**
set XMX_SUN_32BIT=**3072**
set XMS_JROCKIT_64BIT=**256**
set XMS_JROCKIT_32BIT=**256**
set XMX_JROCKIT_64BIT=**1024**
set XMX_JROCKIT_32BIT=**1024**

if "%JAVA_VENDOR%"=="Sun" (
    set WLS_MEM_ARGS_64BIT=**-Xms256m -Xmx512m**
    set WLS_MEM_ARGS_32BIT=**-Xms256m -Xmx512m**
) else (
    set WLS_MEM_ARGS_64BIT=**-Xms512m -Xmx512m**
    set WLS_MEM_ARGS_32BIT=**-Xms512m -Xmx512m**
)

i

set MEM_PERM_SIZE_64BIT=-XX:PermSize=**256m**
set MEM_PERM_SIZE_32BIT=-XX:PermSize=**256m**

if "%JAVA_USE_64BIT%"=="true" (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT%
) else (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT%
)

set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=**1024m**
set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=**1024m**

W Netbeans pomocne może być zaprojektowanie maksymalnego rozmiaru sterty. Idź do Uruchom => Ustaw konfigurację projektu => Dostosuj . W oknie Uruchom wyskakującego okna przejdź do opcji VM , wypełnij -Xms2048m -Xmx2048m. Może rozwiązać problem z wielkością sterty.

Ponowne uruchomienie mojego MacBooka rozwiązało ten problem.

Nie wiem, czy to nadal jest istotne, czy nie, ale chcę tylko podzielić się tym, co dla mnie zadziałało.

Zaktualizuj wersję kotlin do najnowszej dostępnej. https://blog.jetbrains.com/kotlin/category/releases/

i gotowe.