java.lang.outofMemoryError: l'espace de tas java indique une mémoire de tas insuffisante et doit vérifier le traitement des grands objets, des fuites de mémoire et des paramètres de tas, et localiser et optimiser le code via l'outil d'analyse du vidage du tas; 2. Les erreurs de métaspace sont courantes dans la génération de classe dynamique ou le déploiement à chaud en raison des métadonnées de classe excessive, et MaxMetAspaceSize doit être restreint et la charge de classe doit être optimisée; 3. Impossible de créer un nouveau thread natif en raison des ressources de threads système épuisantes, il est nécessaire de vérifier le nombre de threads, d'utiliser des pools de threads et de régler la taille de la pile; 4. La limite de frais généraux GC dépassé signifie que GC est fréquente mais a moins de recyclage et que les journaux GC doivent être analysés, le cycle de vie de l'objet doit être optimisé et le G1GC et d'autres recycler doivent être remplacés; 5. La taille du tableau demandé dépasse la limite de VM est causée par le débordement de longueur du tableau, et la logique de longueur doit être vérifiée pour éviter le débordement entier, et les fichiers volumineux sont traités à l'aide de streaming; Résumé: Le blindage de tas et le journal GC doivent être activés, combinés avec le dépannage des outils d'analyse et résoudre des problèmes de gestion des ressources du niveau de conception du code, plut?t que d'augmenter la mémoire, ce qui peut résoudre fondamentalement le problème OOM.

Java OutOfMemoryError est une erreur critique courante au moment de l'exécution, indiquant généralement que le JVM ne peut pas allouer des objets car la mémoire du tas ou d'autres zones de mémoire sont épuisées. Bien que le message d'erreur puisse sembler simple, il y a de nombreuses raisons derrière. Les éléments suivants sont plusieurs scénarios d' OutOfMemoryError et leurs dépannages et leurs solutions.

1. java.lang.OutOfMemoryError: Java heap space

Il s'agit du type le plus courant, indiquant que la mémoire du tas est insuffisante pour allouer de nouveaux objets.

Raisons courantes:

• L'application charge une grande quantité de données (telles que les fichiers gros, cache les données complètes).
• Il y a une fuite de mémoire (comme l'ajout constant d'objets dans les collections statiques n'est pas nettoyé).
• Les paramètres de mémoire de tas sont trop petits pour répondre aux besoins commerciaux normaux.

étapes de dépannage:

• Afficher le journal des erreurs : confirmez s'il est déclenché lors du traitement des grands objets ou des données par lots.
• Moniteur à l'aide de paramètres JVM :

   -XMX2G -XMS2G -XX: HeapDumponOutOfMemoryError -xx: HeapDumpPath = / Path / To / Dumps

  Cela génère un fichier de vidage de tas (vidage du tas) lorsque OOM.

  
• Analyser le vidage du tas : utilisez des outils tels que Eclipse Mat ou VisualVM pour ouvrir le fichier .hprof pour trouver les objets qui consomment le plus de mémoire et leurs cha?nes de référence.
• Vérifiez le code : concentrez-vous sur:
  • Si Map et List statiques se développent à l'infini.
  • Que le cache n'a pas de mécanisme d'expiration (il est recommandé d'utiliser des caches avec des stratégies obsolètes telles que WeakHashMap ou Caffeine ).
  • Que ce soit pour charger des fichiers volumineux ou des données complètes de la base de données en même temps.

Solution:

• Augmenter la mémoire de tas (solution temporaire):

   -Xmx4g

• Correction du code de fuite de mémoire.
• Traitement de pagination des mégadonnées pour éviter le chargement ponctuel.

2. java.lang.OutOfMemoryError: Metaspace

JDK 8 et plus tard, Permgen est remplacé par Metaspace pour stocker les métadonnées des classes.

Raisons courantes:

• L'application génère dynamiquement un grand nombre de classes (comme l'utilisation de CGLIB, ASM, proxy dynamique, scripts groovy, etc.).
• Déployez un grand nombre d'applications de guerre (telles que les chargeurs de classe à tomcat à chaud non nettoyés).
• La taille Metaspace n'est pas limitée ou est réglée trop petite.

Méthode de dépannage:

• Ajoutez des paramètres JVM pour observer l'utilisation de Metaspace:

   -Xx: maxMetAspaceSize = 512M -Verbose: GC -xx: printgcdetails

• Utilisez jstat -gc <pid> pour afficher MCMN , MCMX , MC (Capacité Metaspace) et d'autres indicateurs.
• Générer et analyser le vidage du tas (bien que Metaspace ne soit pas dans le tas, il peut aider à juger de la situation de chargement de classe).

Solution:

• La définition d'un MaxMetaspaceSize raisonnable empêche une croissance illimitée.
• Vérifiez le chargement / déchargement fréquent des cours, en particulier pour les scénarios de déploiement à chaud.
• Optimiser le comportement GC avec -XX: UseG1GC et -XX:MetaspaceSize=256m .
• évitez la surutilisation de la génération de bytecode d'exécution.

3. java.lang.OutOfMemoryError: Unable to create new native thread

Le JVM tente de créer un nouveau thread, mais le système d'exploitation ne peut pas allouer des ressources de threads natives.

Raisons courantes:

• Le nombre de threads dépasse la limite du système (limite de processus utilisateur ulimit -u ).
• La mémoire système est insuffisante et chaque thread prend 1 Mo d'espace de pile par défaut ( -Xss ).
• L'application a créé trop de threads (tels que le pool de threads n'étant pas utilisé, la fuite de thread).

Méthode de dépannage:

• Vérifiez le nombre actuel de threads:

   ps -elf | grep java | wc -l

• Afficher les restrictions du système:

   Processus utilisateur ulimit -u # max
  chat / proc / sys / noyau / threads-max

• Vérifiez le vidage de thread JVM:

   jstack <pid>> thread_dump.txt

  Vérifiez s'il y a un grand nombre de threads ou de threads similaires qui ne se terminent pas.

Solution:

• Utilisez un pool de thread (comme ThreadPoolExecutor ) au lieu de créer manuellement des threads.
• Redimensionner la pile de threads (prudent):

   -XSS256K # Réduisez la mémoire par pile de threads

• Augmenter les restrictions du système (autorisation d'administrateur requise):

   ulimit -u 65535

• Vérifiez si un thread n'est pas fermé correctement (tel que executor.shutdown() n'est pas appelé).

4. java.lang.OutOfMemoryError: GC overhead limit exceeded

Le JVM passe beaucoup de temps à faire du GC (plus de 98%), mais recycle très peu de mémoire (moins de 2%), et cette erreur est automatiquement lancée.

Raisons courantes:

• Il y a un grand nombre d'objets de ?mort lente? dans le tas, avec des GC fréquents mais de mauvais résultats.
• Hors de la mémoire ou des fuites de mémoire mènent à un espace libre serré.

Méthode de dépannage:

• Activer la journalisation GC:

   -Xlog: gc *, gc tas = debug: file = gc.log: time

• Analysez la fréquence GC et le volume de récupération dans le journal.
• Combiné avec du vidage du tas pour afficher la distribution des objets.

Solution:

• Augmenter la mémoire du tas.
• Optimisez le cycle de vie de l'objet et évitez de tenir des objets inutiles pendant longtemps.
• Utilisez plut?t des collectionneurs de déchets plus efficaces tels que G1GC ou ZGC:

   -Xx: useg1gc

• Vérifiez si les grands objets sont fréquemment créés (tels que les grandes cha?nes, les grands tableaux).

5. java.lang.OutOfMemoryError: Requested array size exceeds VM limit

Essayez de créer un tableau qui dépasse la limite JVM (comme new int[Integer.MAX_VALUE] ).

Raisons courantes:

• L'entier déborde lors du calcul de la taille du tableau, résultant en un nombre négatif ou une valeur maximale demandée.
• La logique de traitement des données est erronée, traitant par erreur la taille du fichier comme la longueur du tableau.

Exemple:

 int size = (int) file.length (); // Lorsque le fichier est supérieur à 2 Go, il sera forcé d'octet négatif [] data = nouveau octet [taille]; // oom peut être déclenché

Solution:

• Utilisez long pour déterminer la taille des données et limiter l'allocation maximale.
• Utilisez des fichiers volumineux en streaming pour éviter le chargement à la fois.
• Vérifiez la logique de calcul de la longueur du tableau pour éviter le débordement.

Résumé des suggestions

Lorsque vous rencontrez OutOfMemoryError , ne transformez pas la mémoire en problème. Les étapes clés comprennent:

• ? Activer -XX: HeapDumpOnOutOfMemoryError
• ? Ajouter des journaux GC et des capacités de vidage de thread
• ? Utilisez des outils d'analyse (Mat, VisualVM, JSTAT, JSTACK)
• ? Revoir les collections, les caches, les threads, la logique de traitement des IO dans le code

L'essence de la plupart des problèmes OOM est une mauvaise conception de code ou une gestion des ressources, et seule une configuration raisonnable et une enquête minutieuse peuvent être résolues.

Fondamentalement, tout est, pas compliqué, mais il est facile d'ignorer les détails.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!