Ik krijg dit foutbericht omdat ik mijn Junit-tests uitvoert:
java.lang.OutOfMemoryError: GC overhead limit exceeded
Ik weet wat een OutOfMemoryError
is, maar wat betekent GC overhead limiet? Hoe kan ik dit oplossen?
Antwoord 1, Autoriteit 100%
Dit bericht betekent dat de afvalcollector om een of andere reden een overmatige hoeveelheid tijd neemt (standaard 98% van alle CPU-tijd van het proces) en herstelt zeer weinig geheugen in elke run (standaard 2% van de heap) .
Dit betekent effectief dat uw programma stopt met het doen van de vooruitgang en is altijd druk om alleen de garbage-collectie te gebruiken.
Om te voorkomen dat uw aanvraag de CPU-tijd opneemt zonder iets gedaan te krijgen, gooit de JVM deze Error
zodat u de kans hebt om het probleem te diagnosticeren.
De zeldzame gevallen waarin ik heb gezien, is waar een code ton tijdelijke objecten en tonnen van zwak gemaakte objecten in een al zeer geheugen-beperkte omgeving creëerde.
Bekijk de Java GC Tuning-gids, die beschikbaar is voor verschillende Java-versies en bevat secties over dit specifieke probleem:
- Java 11 Tuning gids heeft speciale secties over overmatige GC voor Verschillende vuilnisverzamelaars:
- voor de Parallelle collector
- voor de Concurrent Mark Sweep (CMS) Collector
- er is geen melding gemaakt van deze specifieke foutconditie voor de Garbage First (G1) inzamelaar.
- Java 8-afstemgidsen de Overmatige GC-sectie
- Java 6-afstemgidsen zijn Overmatige GC-sectie.
Antwoord 2, autoriteit 28%
Citaat uit het artikel van Oracle ” Java SE 6 HotSpot[tm] Vuilnisinzameling afstemmen op virtuele machine”:
Overmatige GC-tijd en OutOfMemoryError
De parallelle collector gooit een OutOfMemoryError als er te veel tijd wordt besteed aan het verzamelen van afval: als meer dan 98% van de totale tijd wordt besteed aan het verzamelen van afval en minder dan 2% van de heap wordt hersteld, wordt een OutOfMemoryError gegooid. Deze functie is ontworpen om te voorkomen dat applicaties voor een langere periode draaien terwijl ze weinig of geen vooruitgang boeken omdat de heap te klein is. Indien nodig kan deze functie worden uitgeschakeld door de optie
-XX:-UseGCOverheadLimit
toe te voegen aan de opdrachtregel.
EDIT: het lijkt erop dat iemand sneller kan typen dan ik 🙂
Antwoord 3, autoriteit 12%
Als u zeker weet dat er geen geheugenlekkenin uw programma zijn, probeer:
- Vergroot de heapgrootte, bijvoorbeeld
-Xmx1g
. - Schakel de gelijktijdige lage-pauzecollector
-XX:+UseConcMarkSweepGC
in. - Hergebruik bestaande objecten indien mogelijk om wat geheugen te besparen.
Zo nodig de limietcontrole kan worden uitgeschakeld door de optie -XX:-UseGCOverheadLimit
toe te voegen aan de opdrachtregel.
Antwoord 4, autoriteit 6%
Het is meestal de code. Hier is een eenvoudig voorbeeld:
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");
}
}
Java 1.6.0_24-b07 gebruiken op een Windows 7 32 bit.
java -Xloggc:gc.log GarbageCollector
Bekijk dan gc.log
- 444 keer geactiveerd met de BAD-methode
- geactiveerd 666 keer met behulp van slechtere methode
- geactiveerd 354 keer met een betere methode
Nu verleende, dit is niet de beste test of het beste ontwerp, maar wanneer geconfronteerd met een situatie waarin u geen keuze hebt, maar het implementeren van een dergelijke lus of bij het omgaan met bestaande code die zich slecht gedraagt, kiezen voor het opnieuw gebruiken van objecten degenen kunnen het aantal keren verminderen dat de vuilniscollector in de weg zit …
Antwoord 5, Autoriteit 5%
Oorzaak voor de fout volgens de JAVA [8] Platform, Standaard Edition Troubleshooting-gids : (nadruk en lijnonderbrekingen toegevoegd)
[…] “GC overhead-limiet overschreden” geeft aan dat de afvalcollector het hele tijd wordt uitgevoerd en het Java-programma maakt zeer trage vooruitgang.
Na een afvalinzameling, als het M Java-proces meer dan ongeveer 98% van zijn tijd doorbrengt, doet het doen van Garbage Collection en als deze minder dan 2% van de heap herstelt en dit tot nu toe heeft gedaan De laatste 5 (compileertijdconstante) opeenvolgende vuilniscollecties, dan een
java.lang.OutOfMemoryError
wordt gegooid. […]
- Verhoog de heapmaat als de huidige hoop niet voldoende is.
- Als u deze foutmelding nog steeds krijgt na het vergroten van het hoopgeheugen, gebruikt u het geheugen Profileringstools zoals Mat (geheugenanalysator tool), visuele VM etc en fix geheugenlekken.
- Upgrade JDK-versie naar de nieuwste versie (1.8.x) of ten minste 1.7.x en gebruik G1GC-algoritme. . Het doorvoerdoel voor de G1 GC is 90 procent aanvraagtijd en 10 procent garbage-inzamelingstijd
-
Afgezien van het instellen van heapgeheugen met –
Xms1g -Xmx2g
, probeer-XX:+UseG1GC -XX:G1HeapRegionSize=n -XX:MaxGCPauseMillis=m -XX:ParallelGCThreads=n -XX:ConcGCThreads=n
Bekijk enkele meer gerelateerde vragen met betrekking tot G1GC
Antwoord 6, Autoriteit 4%
Verhoog gewoon de heapmaat een beetje door deze optie in te stellen in
Uitvoeren → Configuraties uitvoeren → Argumenten → VM-argumenten
-Xms1024M -Xmx2048M
XMS – voor minimale limiet
xmx – voor maximale limiet
Antwoord 7, Autoriteit 2%
Probeer dit
Open de build.gradle
bestand
android {
dexOptions {
javaMaxHeapSize = "4g"
}
}
Antwoord 8, Autoriteit 2%
Voor mij werkten de volgende stappen:
- Open de
eclipse.ini
Bestand -
Wijzigen
-Xms40m -Xmx512m
Naar
-Xms512m -Xmx1024m
-
Restart Eclipse
Antwoord 9
Het volgende werkte voor mij. Voeg gewoon het volgende fragment toe:
android {
compileSdkVersion 25
buildToolsVersion '25.0.1'
defaultConfig {
applicationId "yourpackage"
minSdkVersion 10
targetSdkVersion 25
versionCode 1
versionName "1.0"
multiDexEnabled true
}
dexOptions {
javaMaxHeapSize "4g"
}
}
Antwoord 10
verhoog javaMaxHeapsize in uw build.gradle(Module:app)-bestand
dexOptions {
javaMaxHeapSize "1g"
}
aan (voeg deze regel stapsgewijs toe)
dexOptions {
javaMaxHeapSize "4g"
}
Antwoord 11
Opgelost:
Gewoon toevoegen
org.gradle.jvmargs=-Xmx1024m
in
gradle.properties
en als het niet bestaat, maak het dan aan.
Antwoord 12
U kunt ook de geheugentoewijzing en de heapgrootte vergroten door dit toe te voegen aan uw gradle.properties
-bestand:
org.gradle.jvmargs=-Xmx2048M -XX\:MaxHeapSize\=32g
Het hoeft niet 2048M en 32g te zijn, maak het zo groot als je wilt.
Antwoord 13
Java heap-groottebeschrijvingen (xms, xmx, xmn)
-Xms size in bytes
Example : java -Xms32m
Stelt de initiële grootte van de Java-heap in.
De standaardgrootte is 2097152 (2 MB).
De waarden moeten een veelvoud zijn van en groter zijn dan 1024 bytes (1 KB).
(De vlag -server verhoogt de standaardgrootte tot 32M.)
-Xmn size in bytes
Example : java -Xmx2m
Stelt de initiële Java-heapgrootte in voor de Eden-generatie.
De standaardwaarde is 640K.
(De vlag -server vergroot de standaardgrootte tot 2M.)
-Xmx size in bytes
Example : java -Xmx2048m
Stelt de maximale grootte in waarop de Java-heap kan groeien.
De standaardgrootte is 64M.
(De vlag -server verhoogt de standaardgrootte tot 128M.)
De maximale heaplimiet is ongeveer 2 GB (2048 MB).
Java-geheugenargumenten (xms, xmx, xmn) opmaak
Als u de Java-heapgrootte instelt, moet u uw geheugenargument specificeren met een van de letters “m” of “M” voor MB, of “g” of “G” voor GB. Uw instelling werkt niet als u “MB” of “GB” opgeeft. Geldige argumenten zien er als volgt uit:
-Xms64m of -Xms64M
-Xmx1g of -Xmx1G
Kan ook 2048 MB gebruiken om 2 GB op te geven
Zorg er ook voor dat u alleen hele getallen gebruikt bij het specificeren van uw argumenten. Het gebruik van -Xmx512m is een geldige optie, maar -Xmx0.5g zal een fout veroorzaken.
Deze referentie kan nuttig zijn voor iemand.
Antwoord 14
Ik werk in Android Studio en ben deze fout tegengekomen bij het genereren van een ondertekende APK voor release.
Ik kon probleemloos een debug-APK bouwen en testen, maar zodra ik een release-APK wilde bouwen, zou het bouwproces minutenlang duren en uiteindelijk eindigen met de “Error java.lang.OutOfMemoryError: GC overheadlimiet overschreden”. Ik heb de heapgroottes voor zowel de VM als de Android DEX-compiler vergroot, maar het probleem bleef bestaan.
Eindelijk, na vele uren en kopjes koffie bleek dat het probleem in mijn app-level ‘build.gradle’-bestand zat – ik had de ‘minifyEnabled’-parameter voor het release-buildtype ingesteld op ‘false’, met als gevolg dat ik Proguard-stuffs draaide op code die het code-shrinking-proces niet heeft doorlopen (zie https: //developer.android.com/studio/build/shrink-code.html).
Ik heb de parameter ‘minifyEnabled’ gewijzigd in ‘true’ en de release-build is als een droom uitgevoerd 🙂
Kortom, ik moest mijn ‘build.gradle’-bestand op app-niveau wijzigen van:
//…
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
}
}
//...
naar
//...
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
}
}
//...
Antwoord 15
Volg de volgende instructies om de heapgrootte in IntelliJ IDEA te vergroten. Het werkte voor mij.
Voor Windows-gebruikers,
Ga naar de locatie waar IDE is geïnstalleerd en zoek naar het volgende.
idea64.exe.vmoptions
Bewerk het bestand en voeg het volgende toe.
-Xms512m
-Xmx2024m
-XX:MaxPermSize=700m
-XX:ReservedCodeCacheSize=480m
Dat is het !!
Antwoord 16
u kunt proberen wijzigingen aan te brengen in de serverinstelling door naar deze afbeelding te verwijzen en de geheugengrootte voor verwerking te vergroten
proceswijzigingen geel gemarkeerd
je kunt ook wijzigingen aanbrengen in java heap door cmd-> set _java_opts -Xmx2g
2g (2gigabyte) afhankelijk van de complexiteit van uw programma
probeer minder constante variabelen en tijdelijke variabelen te gebruiken
Antwoord 17
U moet de geheugengrootte in Jdeveloper vergroten, ga naar 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**
)
en
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**
Antwoord 18
In Netbeans kan het handig zijn om een maximale heapgrootte te ontwerpen. Ga naar Uitvoeren=> Projectconfiguratie instellen=> Aanpassen. Ga in de Runvan het pop-upvenster naar VM Option, vul -Xms2048m -Xmx2048m
in. Het zou het probleem van de heapgrootte kunnen oplossen.
Antwoord 19
Ik weet niet of dit nog steeds relevant is of niet, maar ik wil gewoon delen wat voor mij werkte.
Update de kotlin-versie naar de nieuwste beschikbare. https://blog.jetbrains.com/kotlin/category/releases/
en het is klaar.
Antwoord 20
Het herstarten van mijn MacBook loste dit probleem voor mij op.