Erreur java.lang.OutOfMemoryError: dépassement de la limite de surcharge du GC

Je reçois ce message d'erreur lorsque j'exécute mes tests JUnit:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Je sais ce qu'est un OutOfMemoryError, mais que signifie la limite de frais généraux du GC? Comment puis-je resoudre ceci?

Ce message signifie que pour une raison quelconque, le garbage collector prend trop de temps (par défaut 98% de tout le temps CPU du processus) et récupère très peu de mémoire à chaque exécution (par défaut 2% du tas).

Cela signifie effectivement que votre programme cesse de faire des progrès et est occupé à exécuter uniquement la récupération de place à tout moment.

Pour empêcher votre application d'absorber le temps CPU sans rien faire, la JVM le lance Errorafin que vous ayez une chance de diagnostiquer le problème.

Les rares cas où j'ai vu cela se produire sont ceux où du code créait des tonnes d'objets temporaires et des tonnes d'objets faiblement référencés dans un environnement déjà très limité en mémoire.

Consultez le guide de réglage Java GC, qui est disponible pour différentes versions de Java et contient des sections sur ce problème spécifique:

• Le guide de réglage de Java 11 contient des sections dédiées sur le GC excessif pour différents récupérateurs de place:
  • pour le collecteur parallèle
  • pour le collectionneur simultané Mark Sweep (CMS)
  • il n'y a aucune mention de cette condition d'erreur spécifique pour le collecteur Garbage First (G1).
• Guide de réglage de Java 8 et sa section GC excessive
• Guide de réglage de Java 6 et sa section GC excessive .

Citation de l'article d'Oracle "Java SE 6 HotSpot [tm] Virtual Machine Garbage Collection Tuning" :

Temps GC excessif et OutOfMemoryError

Le collecteur parallèle lancera une OutOfMemoryError si trop de temps est passé dans la récupération de place: si plus de 98% du temps total est consacré à la récupération de place et moins de 2% du tas est récupéré, une OutOfMemoryError sera levée. Cette fonctionnalité est conçue pour empêcher les applications de s'exécuter pendant une longue période tout en faisant peu ou pas de progrès car le tas est trop petit. Si nécessaire, cette fonctionnalité peut être désactivée en ajoutant l'option -XX:-UseGCOverheadLimità la ligne de commande.

EDIT: on dirait que quelqu'un peut taper plus vite que moi :)

Si vous êtes sûr qu'il n'y a aucune fuite de mémoire dans votre programme, essayez de:

1. Augmentez la taille du segment de mémoire, par exemple -Xmx1g.
2. Activez le collecteur de pause faible simultané -XX:+UseConcMarkSweepGC.
3. Réutilisez les objets existants lorsque cela est possible pour économiser de la mémoire.

Si nécessaire, la vérification des limites peut être désactivée en ajoutant l'option -XX:-UseGCOverheadLimità la ligne de commande.

C'est généralement le code. Voici un exemple simple:

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");
    }
}

Utilisation de Java 1.6.0_24-b07 sur Windows 7 32 bits.

java -Xloggc:gc.log GarbageCollector

Regardez ensuite gc.log

• Déclenché 444 fois à l'aide de la méthode BAD
• Déclenché 666 fois en utilisant la méthode PIRE
• Déclenché 354 fois en utilisant la meilleure méthode

Maintenant accordé, ce n'est pas le meilleur test ou la meilleure conception, mais face à une situation où vous n'avez pas d'autre choix que d'implémenter une telle boucle ou lorsque vous traitez avec du code existant qui se comporte mal, choisir de réutiliser des objets au lieu d'en créer de nouveaux peut réduire le nombre de fois où le ramasse-miettes gêne ...

Cause de l'erreur selon la plate-forme Java [8], Guide de dépannage de l'édition standard : (accentuation et sauts de ligne ajoutés)

[...] "La limite de surcharge GC est dépassée" indique que le garbage collector fonctionne tout le temps et que le programme Java progresse très lentement.

Après un garbage collection, si le processus Java passe plus de 98% de son temps à faire le garbage collection et s'il récupère moins de 2% du tas et a effectué jusqu'à présent les 5 derniers (constante de temps de compilation) ordures consécutives collections, puis un java.lang.OutOfMemoryErrorest jeté. [...]

1. Augmentez la taille du tas si le tas actuel n'est pas suffisant.
2. Si vous obtenez toujours cette erreur après avoir augmenté la mémoire du tas, utilisez des outils de profilage de la mémoire comme MAT (outil d'analyseur de mémoire), Visual VM, etc. et corrigez les fuites de mémoire.
3. Mettez à niveau la version JDK vers la dernière version (1.8.x) ou au moins 1.7.x et utilisez l'algorithme G1GC. . L'objectif de débit pour le GC G1 est de 90% du temps d'application et de 10% du temps de collecte des ordures

4. En plus de définir la mémoire de tas avec - Xms1g -Xmx2g, essayez

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

Jetez un oeil à quelques questions plus connexes concernant G1GC

• Collecte des ordures et documentation Java 7 (JDK 7) sur G1

• Collecte des ordures Java G1 en production

• Article sur Oracle Technetwork pour le réglage fin du GC

Augmentez un peu la taille du tas en définissant cette option dans

Exécuter → Configurations d'exécution → Arguments → Arguments de machine virtuelle

-Xms1024M -Xmx2048M

Xms - pour la limite minimale

Xmx - pour la limite maximale

Pour moi, les étapes suivantes ont fonctionné:

1. Ouvrez le eclipse.inidossier

2. Changement

   -Xms40m
   -Xmx512m

   à

   -Xms512m
   -Xmx1024m

3. Redémarrez Eclipse

Vois ici

essaye ça

ouvrir le build.gradledossier

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

Ce qui suit a fonctionné pour moi. Ajoutez simplement l'extrait suivant:

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

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

augmentez javaMaxHeapsize dans votre fichier build.gradle (Module: app)

dexOptions {
    javaMaxHeapSize "1g"
}

à (ajouter cette ligne en gradle)

 dexOptions {
        javaMaxHeapSize "4g"
    }

Description des tailles de tas Java (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

Définit la taille initiale du tas Java. La taille par défaut est 2097152 (2 Mo). Les valeurs doivent être un multiple de et supérieur à 1024 octets (1 Ko). (L'indicateur -server augmente la taille par défaut à 32 Mo.)

-Xmn size in bytes

Example : java -Xmx2m

Définit la taille initiale du tas Java pour la génération Eden. La valeur par défaut est 640K. (L'indicateur -server augmente la taille par défaut à 2 Mo.)

-Xmx size in bytes

Example : java -Xmx2048m

Définit la taille maximale à laquelle le tas Java peut s'agrandir. La taille par défaut est 64M. (L'indicateur -server augmente la taille par défaut à 128 Mo.) La limite de segment de mémoire maximale est d'environ 2 Go (2048 Mo).

Formatage des arguments de mémoire Java (xms, xmx, xmn)

Lors de la définition de la taille du segment Java, vous devez spécifier votre argument mémoire en utilisant l'une des lettres «m» ou «M» pour MB, ou «g» ou «G» pour GB. Votre paramètre ne fonctionnera pas si vous spécifiez «Mo» ou «Go». Les arguments valides ressemblent à ceci:

-Xms64m ou -Xms64M -Xmx1g ou -Xmx1G Peut également utiliser 2048 Mo pour spécifier 2 Go. Veillez également à n'utiliser que des nombres entiers lors de la spécification de vos arguments. L'utilisation de -Xmx512m est une option valide, mais -Xmx0.5g provoquera une erreur.

Cette référence peut être utile à quelqu'un.

Vous pouvez également augmenter l'allocation de mémoire et la taille du segment de mémoire en l'ajoutant à votre gradle.propertiesfichier:

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

Il ne doit pas nécessairement être 2048M et 32g, rendez-le aussi grand que vous le souhaitez.

Résolu:
Il suffit d' ajouter
org.gradle.jvmargs=-Xmx1024m
dans
gradle.properties
et si elle n'existe pas, créez - le.

Je travaille dans Android Studio et j'ai rencontré cette erreur lors de la tentative de génération d'un APK signé pour publication. J'ai pu créer et tester un APK de débogage sans problème, mais dès que je voulais créer un APK de version, le processus de construction s'exécutait pendant des minutes, puis se terminait finalement par l'erreur "java.lang.OutOfMemoryError: GC dépassement de la limite de frais généraux ". J'ai augmenté les tailles de tas pour la machine virtuelle et le compilateur Android DEX, mais le problème persistait. Enfin, après de nombreuses heures et des tasses de café, il s'est avéré que le problème se trouvait dans mon fichier 'build.gradle' au niveau de l'application - j'avais le paramètre 'minifyEnabled' pour le type de build de la version réglé sur 'false', exécutant par conséquent des trucs Proguard sur du code qui n'a pas subi le processus de réduction de code (voir https://developer.android.). J'ai changé le paramètre 'minifyEnabled' en 'true' et la build de la version exécutée comme un rêve :)

En bref, j'ai dû changer mon fichier 'build.gradle' au niveau de l'application de: // ...

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
    }
}

//...

à

    //...

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
    }
}

//...

Pour augmenter la taille du segment de mémoire dans IntelliJ IDEA, suivez les instructions suivantes. Ça a marché pour moi.

Pour les utilisateurs de Windows,

Accédez à l'emplacement où IDE est installé et recherchez les éléments suivants.

idea64.exe.vmoptions

Modifiez le fichier et ajoutez ce qui suit.

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

C'est ça !!

vous pouvez essayer d'apporter des modifications au paramètre du serveur en vous référant à cette image et augmenter la taille de la mémoire pour le traitement des modifications du processus surlignées en jaune

vous pouvez également apporter des modifications au tas java en ouvrant cmd-> set _java_opts -Xmx2g
2g (2gigabytes) selon la complexité de votre programme

essayez d'utiliser des variables variables et temporaires moins constantes

Vous devez augmenter la taille de la mémoire dans Jdeveloper, accédez à 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**
)

et

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**

Dans Netbeans, il peut être utile de concevoir une taille de segment de mémoire maximale. Accédez à Exécuter => Définir la configuration du projet => Personnaliser . Dans la fenêtre Exécuter de sa fenêtre contextuelle, accédez à Option VM , remplissez -Xms2048m -Xmx2048m. Cela pourrait résoudre le problème de taille de tas.

Le redémarrage de mon MacBook a résolu ce problème pour moi.

Je ne sais pas si cela est toujours pertinent ou non, mais je veux juste partager ce qui a fonctionné pour moi.

Mettre à jour la version kotlin vers la dernière version disponible. https://blog.jetbrains.com/kotlin/category/releases/

et c'est fait.