java.lang.OutOfMemoryError : Limite de surcharge du GC dépassée

Question

J'obtiens cette erreur dans un programme qui crée plusieurs (centaines de milliers) objets HashMap avec quelques (15-20) entrées de texte chacun. Ces chaînes de caractères doivent toutes être rassemblées (sans être divisées en petites quantités) avant d'être soumises à une base de données.

Selon Sun, l'erreur se produit "si trop de temps est consacré à la collecte des déchets : si plus de 98% du temps total est consacré à la collecte des déchets et que moins de 2% du tas est récupéré, un OutOfMemoryError sera lancé".

Apparemment, on pourrait utiliser la ligne de commande pour passer des arguments à la JVM pour

• Augmenter la taille du tas, via "-Xmx1024m" (ou plus), ou
• Désactiver complètement le contrôle d'erreur, via "-XX:-UseGCOverheadLimit".

La première approche fonctionne bien, la seconde aboutit à une autre erreur java.lang.OutOfMemoryError, cette fois-ci concernant le tas.

J'ai donc une question : existe-t-il une alternative programmatique à cela, pour le cas d'utilisation particulier (c'est-à-dire plusieurs petits objets HashMap) ? Si j'utilise la méthode HashMap clear(), par exemple, le problème disparaît, mais les données stockées dans le HashMap aussi ! :-)

La question est également abordée dans un Sujet connexe dans StackOverflow.

Answer 1

Vous manquez essentiellement de mémoire pour faire fonctionner le processus de manière fluide. Les options qui viennent à l'esprit :

1. Spécifiez plus de mémoire comme vous l'avez mentionné, essayez quelque chose entre les deux comme -Xmx512m premièrement
2. Travaillez avec de plus petits lots de HashMap les objets à traiter en une seule fois si possible
3. Si vous avez beaucoup de chaînes de caractères en double, utilisez [String.intern()](http://java.sun.com/javase/7/docs/api/java/lang/String.html#intern()) sur eux avant de les mettre dans le HashMap
4. Utilisez le HashMap(int initialCapacity, float loadFactor) pour s'adapter à votre cas

Answer 2

@takrl : Le paramètre par défaut de cette option est :

java -XX:+UseConcMarkSweepGC

ce qui signifie que cette option n'est pas active par défaut. Donc quand vous dites que vous avez utilisé l'option " +XX:UseConcMarkSweepGC " Je suppose que vous utilisiez cette syntaxe :

java -XX:+UseConcMarkSweepGC

ce qui signifie que vous activiez explicitement cette option. Pour connaître la syntaxe correcte et les paramètres par défaut de Java HotSpot VM Options @ ceci document

Answer 3

Pour mémoire, nous avons eu le même problème aujourd'hui. Nous l'avons résolu en utilisant cette option :

-XX:-UseConcMarkSweepGC

Apparemment, cela a modifié la stratégie utilisée pour la collecte des déchets, ce qui a fait disparaître le problème.

Answer 4

Ummm... vous devrez soit :

1. Repensez complètement votre algorithme et vos structures de données, de sorte qu'ils n'aient pas besoin de tous ces petits HashMaps.

2. Créez une façade qui vous permette de faire entrer et sortir ces HashMaps de la mémoire selon vos besoins. Un simple cache LRU pourrait faire l'affaire.

3. Augmente la mémoire disponible pour la JVM. Si nécessaire, même l'achat de plus de RAM pourrait être la solution la plus rapide et la plus économique, si vous avez la gestion de la machine qui héberge cette bête. Cela dit : Je ne suis généralement pas un adepte des solutions du type "ajouter du matériel", surtout si une solution algorithmique alternative peut être trouvée dans un délai raisonnable. Si vous continuez à injecter plus de matériel dans chacun de ces problèmes, vous vous heurtez rapidement à la loi des rendements décroissants.

Qu'est-ce que vous essayez de faire en fait ? Je pense qu'il y a une meilleure approche pour votre problème réel.

Answer 5

Utiliser une implémentation alternative de HashMap ( Trove ). Le HashMap standard de Java a une surcharge mémoire >12x. On peut lire les détails aquí .