L'analyse des vidages de tas Java est un moyen clé pour résoudre les problèmes de mémoire, en particulier pour identifier les fuites de mémoire et les goulots d'étranglement des performances. 1. Utilisez Eclipse Mat ou VisualVM pour ouvrir le fichier .hprof. Le MAT fournit des vues d'histogramme et d'arborescence Dominator pour afficher la distribution d'objet sous différents angles; 2. Trier en histogramme par nombre d'instances ou d'espace occupé pour trouver des classes avec des tailles anormalement grandes ou grandes, telles que l'octet [], le char [] ou les classes de commerce; 3. Affichez la cha?ne de référence via "Liste des objets> avec des références entrantes / sortantes" pour déterminer si elle est accidentellement détenue; 4. Utilisez la fonction "Path to GC Roots" pour éliminer les références virtuelles / souples / faibles, localiser des chemins de référence solides et identifier des problèmes tels que le cache non d'atelier, les auditeurs ungulgés, une mauvaise utilisation du threadlocal; 5. Utiliser l'arborescence Dominator Vérifiez la valeur du tas conservée, déterminer quels objets peuvent libérer beaucoup de mémoire après avoir été libéré et étendre davantage la zone dominante pour analyser la structure de mémoire globale. La ma?trise de ces étapes de clé peut rapidement localiser la plupart des problèmes de mémoire.

L'analyse des vidages de tas Java est un moyen important de résoudre les problèmes de mémoire, en particulier lorsqu'il s'agit de fuites de mémoire ou d'étranglements de performances. Le noyau consiste à découvrir des objets à l'occasion de la mémoire, des objets en double ou des cha?nes de référence inattendues via des outils.

Ouvrir un vidage de tas avec les bons outils

Les outils les plus courants sont Eclipse MAT (Memory Analyzer) et VisualVM , où MAT est plus puissant et adapté à une analyse approfondie.
Après avoir téléchargé et installé, utilisez-le pour ouvrir le fichier .hprof directement pour commencer à parcourir la situation de la mémoire du tas.

• MAT affichera des vues telles que "histogramme" et "arbre Dominator", respectivement, affichant la distribution d'objet sous différents angles.
• Si vous voulez juste voir combien d'instances a une certaine classe, l'histogramme est le premier choix.
• Si vous voulez savoir quels objets prennent le plus de mémoire et empêchent la collecte des ordures, l'arbre Dominator est plus approprié.

Trouvez des objets grands et en double en mémoire

Après être entré dans la vue d'histogramme, vous pouvez le trier par le nombre d'instances ou l'empreinte totale. Concentrez-vous sur les classes avec des nombres anormaux ou de grandes tailles d'une seule instance.

Par exemple:

• byte[] ou char[] occupent une occupation élevée, qui peut être mise en cache ou de grandes cordes non libérées;
• Le nombre d'une certaine classe professionnelle (comme User et CacheEntry ) est bien au-delà des attentes, et il peut y avoir des fuites de mémoire;
• Faites attention au nom du package et priorisez la vérification des classes liées au code que vous avez écrit vous-même.

Cliquez pour voir l'instance spécifique, cliquez avec le bouton droit et sélectionnez "Liste des objets> avec des références entrantes / sortantes", vous pouvez afficher la cha?ne de référence et déterminer si elle est accidentellement maintenue.

Analyser la cha?ne de référence et localiser la cause profonde des fuites de mémoire

Les fuites de mémoire sont généralement causées par le fait que les objets ne sont plus utilisés mais ne peuvent pas être recyclés par GC. Ils sont communs dans les collections statiques, les auditeurs, les variables locales de fil, etc.

MAT fournit la fonction "chemin vers les racines GC" pour voir pourquoi un objet est toujours vivant. La méthode de fonctionnement est:

• Cliquez avec le bouton droit sur l'objet suspect
• Sélectionnez "Fusiter le chemin le plus court vers les racines GC" → Ne vérifiez pas "Références virtuelles / doux / vent", ne regardez que le chemin de référence fort

De cette fa?on, vous pouvez voir qui "étreint" l'objet. Les "coupables" courants comprennent:

• Cache non nettoyée (en particulier le hashmap sans mécanisme d'expiration)
• écouteur non déconnecté (comme l'écoute des événements, le mode observateur)
• Utilisation inappropriée des causes de threadlocal Données résiduelles dans le pool de threads

Utilisez l'arbre Dominator si nécessaire

Dominator Tree montre la relation de "qui contr?le qui" c'est-à-dire, si l'objet a est recyclé, alors tous les objets en dessous sont recyclés. Ceci est très utile pour juger la structure de mémoire globale.

Dans ce point de vue, vous pouvez voir la valeur "tas conservée" pour chaque n?ud, représentant la quantité de mémoire peut être libérée si l'objet est libéré. Plus la valeur est grande, plus vous méritez de prêter attention.

Si vous constatez qu'un tas de tas conservé est particulièrement élevé, vous pouvez étendre davantage sa zone dominante pour voir si plusieurs objets enfants sont impliqués en même temps.

Fondamentalement, c'est tout. L'analyse du vidage de tas n'est pas particulièrement compliquée, mais il est facile d'ignorer les détails, tels que les types de référence, les chemins réels des racines GC. Comprenez simplement quelques vues clés et méthodes de fonctionnement pour localiser rapidement la plupart des problèmes de mémoire.

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!