Heim  >  Artikel  >  Backend-Entwicklung  >  Analyse der .NET Garbage Collection (GC)-Prinzipien

Analyse der .NET Garbage Collection (GC)-Prinzipien

怪我咯
怪我咯Original
2017-04-05 13:33:441419Durchsuche

Als Teil des erweiterten .NET-Inhalts müssen Sie den Garbage Collector (kurz GC) verstehen. Gemäß dem Prinzip „leicht verständlich“ wird in diesem Artikel das Funktionsprinzip des Garbage Collectors in der CLR erläutert.

Grundkenntnisse

Managed Heap

Schauen wir uns zunächst die Erklärung von MSDN an: Wenn ein neuer Prozess initialisiert wird, wird er für den Prozess reserviert Laufzeit Ein zusammenhängender Bereich des Adressraums. Dieser reservierte Adressraum wird als verwalteter Heap bezeichnet.

„Der verwaltete Heap ist auch ein Heap“, warum sagen Sie das? Ich sage das, weil ich hoffe, dass nicht jeder durch die „Terminologie“ verwirrt wird. Die Prämisse dieses Wissenspunkts ist „der Unterschied zwischen Werttyp und Referenztyp “. Es wird hier davon ausgegangen, dass der Leser bereits das wichtige Konzept kennt: „Werttypen werden auf dem Stapel gespeichert und Referenztypen werden auf dem Heap gespeichert. (Referenzen von Referenztypen werden auf dem Stapel gespeichert)“. Nach dieser Theorie erfordert die CLR also, dass alle Ressourcen mit Ausnahme der Werttypen vom verwalteten Heap zugewiesen werden.

Der verwaltete Heap verwaltet einen Zeiger, hier NextObjPtr genannt, der auf den Zuordnungsort des nächsten Objekts im Heap zeigt.

CPU-Register

Dies sind grundlegende Computerkenntnisse, um die folgenden „Grundkonzepte“ zu verstehen.

CPU-Register sind der eigene „temporäre Speicher“ der CPU, der schneller ist als der Speicherzugriff. Geteilt durch die Entfernung von der CPU sind die nächstgelegenen Register, dann Cache (Cache der Computerebene eins, Ebene zwei und Ebene drei) und schließlich der Speicher.

Wurzeln

Alle statischen -Felder, die in der -Klasse definiert sind, Parameter von Methoden, lokale -Variablen

(nur Referenztypvariablen) usw Sie sind alle Roots, und die Objektzeiger in den CPU-Registern sind ebenfalls Roots. Roots sind die verschiedenen Einstiegspunkte, die die CLR außerhalb des Heaps finden kann.

Objekte erreichbar und nicht erreichbar

Wenn sich ein Stamm auf ein Objekt im Heap bezieht, ist das Objekt „erreichbar“ „erreichbar“, andernfalls ist es „ unerreichbar“.

Der Grund für die Speicherbereinigung

Aus Sicht der Computerkomposition müssen sich alle Programme im Speicher befinden und ausgeführt werden. Und der Speicher ist ein limitierender Faktor (Größe). Darüber hinaus gelten für den verwalteten Heap auch Größenbeschränkungen. Wenn der verwaltete Heap keine Größenbeschränkung hat, ist die Ausführungsgeschwindigkeit von C#

besser als die von c (die Struktur des verwalteten Heaps ermöglicht eine schnellere Zuweisung von Objekten als der C-Laufzeit-Heap). Aufgrund von Adressraum- und Speicherbeschränkungen muss der verwaltete Heap seinen normalen Betrieb über einen Garbage-Collection-Mechanismus aufrechterhalten, um sicherzustellen, dass Objekte ohne „Speicherüberlauf“ zugewiesen werden.

Grundprinzipien der Garbage Collection

Recycling ist in zwei Phasen unterteilt: Markieren –> Komprimieren Der Prozess der

Markierung ist eigentlich der Prozess der Bestimmung, ob ein Objekt erreichbar ist. Wenn alle Wurzeln überprüft wurden, enthält der Heap erreichbare (markierte) und nicht erreichbare (nicht markierte) Objekte.

Nachdem die Markierung abgeschlossen ist, treten Sie in die Komprimierungsstufe ein. Während dieser Phase durchläuft der Garbage Collector linear den Heap, um zusammenhängende Speicherblöcke für nicht erreichbare Objekte zu finden. Und verschieben Sie erreichbare Objekte hierher, um den Heap zu komprimieren. Dieser Vorgang ähnelt in gewisser Weise der Defragmentierung von Speicherplatz.

Wie im Bild oben gezeigt, stellt das grüne Kästchen das erreichbare Objekt und das gelbe Kästchen das nicht erreichbare Objekt dar. Nachdem nicht erreichbare Objekte gelöscht wurden, wird durch das Verschieben erreichbarer Objekte eine Speicherkomprimierung erreicht (die kompakter wird).

Nach der Komprimierung sind die „Zeiger auf diese Objekte“ der Variablen und CPU-Register nun ungültig, und der Garbage Collector muss alle Wurzeln erneut aufrufen und sie so ändern, dass sie auf die neuen Speicherorte der Objekte verweisen. Dies kann zu erheblichen Leistungseinbußen führen. Dieser Verlust ist auch der Hauptnachteil des verwalteten Heaps.

Aufgrund der oben genannten Merkmale ist auch der durch die Müllabfuhr verursachte Recyclingalgorithmus ein Forschungsthema. Denn wenn Sie warten, bis der verwaltete Heap voll ist, bevor Sie mit der Garbage Collection beginnen, wird dieser sehr „langsam“.

Garbage-Collection-Algorithmus – Generierungsalgorithmus

Die Generierung ist ein Mechanismus, der vom CLR-Garbage Collector verwendet wird. Sein einziger Zweck besteht darin, die Leistung der Anwendung zu verbessern. Das generationsübergreifende Recycling ist offensichtlich schneller als das Recycling des gesamten Haufens.

Der CLR-verwaltete Heap unterstützt drei Generationen: Generation 0, Generation 1 und Generation 2. Der Speicherplatz der Generation 0 beträgt etwa 256 KB, der der Generation 1 etwa 2 MB und der der Generation 2 etwa 10 MB. Das neu erstellte Objekt wird der Generation 0 zugeordnet,

Wie in der Abbildung oben gezeigt, Wenn der Raum der Generation 0 voll ist, beginnt der Müllsammler mit dem Recycling

, nicht erreichbare Objekte (C und E in der Abbildung oben) werden recycelt und überlebende Objekte werden als Objekte der ersten Generation klassifiziert.

Wenn der Raum der Generation 0 voll ist und der Raum der Generation 1 beginnt, viele unerreichbare Objekte zu haben, sodass der Raum fast voll ist, wird der Müll beider Generationen recycelt . Für überlebende Objekte (erreichbare Objekte) wird Generation 0 auf Generation 1 und Generation 1 auf Generation 2 hochgestuft.

Der eigentliche Sammelmechanismus der CLR-Generation ist „intelligenter“. Wenn das neu erstellte Objekt einen kurzen Lebenszyklus hat, wird der Müll der 0. Generation sofort vom Garbage Collector recycelt (ohne darauf zu warten, dass der Speicherplatz voll ist). zugewiesen). Wenn außerdem Generation 0 recycelt wird und festgestellt wird, dass noch viele Objekte „erreichbar“ sind und

nicht viel Speicher freigegeben hat, wird das Budget der Generation 0 auf 512 KB erhöht, und der Recyclingeffekt wird erhöht umgewandelt werden in: Die Anzahl der Speicherbereinigungen wird reduziert, aber jedes Mal wird eine große Menge Speicher zurückgefordert. Wenn nicht viel Speicher freigegeben wurde, führt der Garbage Collector eine vollständige Wiederverwendung (3 Generationen) durch. Wenn immer noch nicht genügend Speicher vorhanden ist, wird eine „Speicherüberlauf“-Ausnahme ausgelöst.

Mit anderen Worten: Der Garbage Collector passt das zugewiesene Speicherplatzbudget jeder Generation basierend auf der Größe des wiederhergestellten Speichers dynamisch an! Erzielen Sie eine automatische Optimierung!

Zusammenfassung

Hinter der Garbage Collection steckt eine Grundidee:

Programmiersprachen

(die meisten) scheinen immer Zugriff auf unbegrenzten Speicher zu haben. Und Entwickler können immer weiter zuweisen, zuweisen und immer wieder zuweisen – wie von Zauberhand, unerschöpflich. Das grundlegende Arbeitsprinzip des .NET-Garbage Collectors besteht darin, nicht erreichbare Objekte durch das einfachste Markierungs- und Löschprinzip zu löschen und dann den verfügbaren Speicher wie eine Festplattendefragmentierung zu komprimieren und schließlich die höchste Leistung durch Optimierung des Generationsalgorithmus zu erzielen .

Das obige ist der detaillierte Inhalt vonAnalyse der .NET Garbage Collection (GC)-Prinzipien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn