Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Bei der Profilerstellung von .NET-Code im Profilerstellungstool Speicherauslastung in Visual Studio kann der hot path to root Ihnen helfen, Objekte zu identifizieren, die auf dem Heap aufbewahrt werden, die Probleme mit der Speicherauslastung verursachen. Im Kontext der Speicherauslastung ist der hot path eine referenzkette, die vom Profiler identifiziert wird, die auf ein Stammobjekt verweist, das eine potenzielle Quelle von Speicherproblemen ist.
Bei der Berechnung der inklusiven Größe eines Objekts (die Gesamtmenge des auf dem Heap beibehaltenen Speichers, indem das Objekt aktiv gehalten wird) ist es häufig hilfreich, das stark verbundene Heapdiagramm in eine Struktur zu reduzieren. Im Gegensatz zu einem Graphen hat ein Knoten in einem Baum beliebig viele Kinder, aber nur ein einzelnes Elternteil. Anstatt jeden möglichen Pfad zum Stamm für ein Objekt zu berücksichtigen, ist die Auswahl des wahrscheinlichsten Pfads zum Stamm mithilfe verschiedener Heuristiken in der Regel ausreichend, um die Verweiskette zu finden, die, wenn sie entfernt wird, das Objekt für die Garbage Collection (GC) berechtigt. Einige dieser Heuristiken umfassen die Priorisierung des kürzesten Pfads zum Stamm, bestimmte Stammtypen und Benutzercodepfade. Aus verschiedenen Gründen findet diese Strategie nicht immer die interessantesten oder längsten Aufbewahrungsketten, bietet häufig aber einen nützlichen Ausgangspunkt in einer Speichernutzungsuntersuchung.
In der Struktur Pfade zum Stamm des Speicherauslastungstools wird der Pfad mit dem Flammensymbol (
) als langsamster Pfad zum Stamm bezeichnet.
Beispiel
Verwenden Sie die Option Nur langsamste Pfade anzeigen, um die Ansicht im Bereich Pfade zum Stamm zu filtern.
In diesem Beispiel wird ein WPF-Steuerelement (AttachToProcess.Dialog) durch eine Bindung durchgelassen, die letztendlich durch AutomationPeer verwurzelt ist. In der gefilterten Ansicht ist der Retentionpfad offensichtlich; nur der direkte Pfad zum Stamm ist sichtbar.
Wenn die Option deaktiviert ist, wird klar, dass hunderte Bindungen vorhanden sind, und die meisten Erweiterungspfade führen in Sackgassen, die sich wiederholen. Ohne den visuellen Indikator ist es mühsam, Tausende potenzieller Aufbewahrungspfade zu sortieren, um einen möglichen Grund für das Leck zu finden.
Siehe auch
Weitere Informationen zum Visual Studio Memory Usage-Tool finden Sie unter