Prinzip des .Net-Garbage-Collection-Mechanismus (2)

Englischer Originaltext: Jeffrey Richter

Zusammengestellt von: Zhao Yukai

Link http://www.php.cn/

Im vorherigen Artikel wurden die Grundprinzipien der .Net-Garbage Collection und der interne Mechanismus der Garbage Collection zur Ausführung der Finalize-Methode vorgestellt. In diesem Artikel betrachten wir schwache Referenzobjekte, Generationen, Multithread-Garbage Collection und große Objekte Leistungsindikatoren für die Verarbeitung und Speicherbereinigung.
Beginnen wir mit schwachen Referenzobjekten. Schwache Referenzobjekte können den durch große Objekte verursachten Speicherdruck verringern.
Schwache Referenzen
Wenn das Stammobjekt des Programms auf ein Objekt zeigt, ist das Objekt erreichbar und der Garbage Collector kann es nicht zurückfordern. Dies wird als starke Referenz auf das Objekt bezeichnet. Das Gegenteil von starken Referenzen sind schwache Referenzen. Wenn es eine schwache Referenz auf ein Objekt gibt, kann der Garbage Collector das Objekt zurückfordern, aber es ermöglicht dem Programm auch, auf das Objekt zuzugreifen. Was ist los? Bitte lesen Sie weiter unten.

Wenn nur schwache Referenzen auf ein Objekt vorhanden sind und der Garbage Collector ausgeführt wird, wird das Objekt recycelt. Wenn später im Programm auf das Objekt zugegriffen wird, schlägt der Zugriff fehl. Um andererseits ein schwach referenziertes Objekt zu verwenden, muss das Programm zunächst einen starken Verweis auf das Objekt erstellen, bevor der Garbage Collector das Objekt sammelt (nachdem es einen starken Verweis hat). Der Garbage Collector wird dieses Objekt nicht recyceln. Das ist etwas kompliziert, lassen Sie es uns anhand eines Codes erklären:

void Method() {
//创建对象的强引用
Object o = new Object(); 
// 用一个短弱引用对象弱引用o.
WeakReference wr = new WeakReference(o);

o = null; // 移除对象的强引用

o = wr.Target; //尝试从弱引用对象中获得对象的强引用
if (o == null) {
// 如果对象为空说明对象已经被垃圾回收器回收掉了
} else {
// 如果垃圾回收器还没有回收此对象就可以继续使用对象了
}
}

Warum brauchen wir schwache Objekte? Denn manche Daten sind einfach zu erstellen, erfordern aber viel Speicher. Beispiel: Sie haben ein Programm, das auf alle Ordner und Dateinamen auf der Festplatte des Benutzers zugreifen muss. Sie können auf die Festplatte des Benutzers zugreifen, um Daten zu generieren, sobald das Programm diese Daten zum ersten Mal benötigt Sie können auf die Daten im Speicher zugreifen, um Benutzerdateidaten abzurufen, anstatt jedes Mal Daten auf der Festplatte abzurufen. Dies kann die Leistung des Programms verbessern.

问题是这个数据可能相当大，需要相当大的内存。如果用户去操作程序的另外一部分功能了，这块相当大的内存就没有占用的必要了。你可以通过代码删除这些数据，但是如果用户马上切换到需要这块数据的功能上，你就必须重新从用户的磁盘上构建这个数据。弱引用为这种场景提供了一种简单有效的方案。
当用户切换到其他功能时，你可以为这个数据创建一个弱引用对象，并把对这个数据的强引用解除掉。这样如果程序占用的内存很低，垃圾回收操作就不会触发，弱引用对象就不会被回收掉；这样当程序需要使用这块数据时就可以通过一个强引用来获得数据，如果成功得到了对象引用，程序就没有必要再次读取用户的磁盘了。

WeakReference类型提供了两个构造函数：

WeakReference(object target);
WeakReference(object target, bool trackResurrection);

target参数显然就是弱引用要跟踪的对象了。trackResurrection参数表示当对象的Finalize方法执行之后是否还要跟踪这个对象。默认这个参数是false。有关对象的复活请参考这里。

Der Einfachheit halber werden schwache Referenzen, die das wiederbelebte Objekt nicht verfolgen, „kurze schwache Referenzen“ genannt, während schwache Referenzen, die die wiederbelebten Objekte verfolgen, „lange schwache Referenzen“ genannt werden. Wenn das Objekt die Finalize-Methode nicht implementiert, sind die lange schwache Referenz und die kurze schwache Referenz genau gleich. Es wird dringend empfohlen, die Verwendung langer schwacher Referenzen zu vermeiden. Lange schwache Referenzen ermöglichen die Verwendung wiederbelebter Objekte, deren Verhalten möglicherweise unvorhersehbar ist.
Sobald Sie WeakReference verwenden, um auf ein Objekt zu verweisen, wird empfohlen, alle starken Referenzen dieses Objekts auf Null zu setzen. Wenn eine starke Referenz vorhanden ist, kann der Garbage Collector das Objekt, auf das die schwache Referenz zeigt, niemals zurückfordern .
Wenn Sie eine schwache Referenz auf das Zielobjekt verwenden möchten, müssen Sie eine starke Referenz für das Zielobjekt erstellen. Dies ist sehr einfach, verwenden Sie einfach object a = WeekRefer.Target; und dann müssen Sie feststellen, ob a leer ist Es kann nur dann weiter verwendet werden, wenn es nicht leer ist. Wenn es schwach leer ist, bedeutet dies, dass das Objekt vom Garbage Collector recycelt wurde und das Objekt auf andere Weise wiedererlangt werden muss.
Interne Implementierung schwacher Referenzen
Aus der vorherigen Beschreibung können wir schließen, dass schwache Referenzobjekte definitiv anders behandelt werden als allgemeine Objekte. Wenn ein Objekt auf ein anderes Objekt verweist, handelt es sich im Allgemeinen um eine starke Referenz, und der Garbage Collector kann das referenzierte Objekt nicht recyceln. Dies ist jedoch nicht der Fall für das WeakReference-Objekt.
Um die Funktionsweise schwacher Objekte vollständig zu verstehen, müssen wir uns auch den verwalteten Heap ansehen. Es gibt zwei interne Datenstrukturen auf dem verwalteten Heap. Ihre einzige Aufgabe besteht darin, schwache Referenzen zu verwalten: Wir können sie als lange schwache Referenztabellen und kurze schwache Referenztabellen bezeichnen, um schwache Referenzzielobjektzeiger auf dem verwalteten Heap zu speichern.
Zu Beginn des Programmablaufs sind beide Tabellen leer. Wenn Sie ein WeakReference-Objekt erstellen, wird das Objekt nicht auf dem verwalteten Heap zugewiesen, sondern es wird ein leerer Slot (Empty Slot) in der Tabelle für schwache Objekte erstellt. Kurze schwache Referenzobjekte werden in die kurze schwache Objekttabelle eingefügt, und lange schwache Referenzobjekte werden in die lange schwache Referenztabelle eingefügt.
Sobald ein leerer Steckplatz gefunden wird, wird der Wert des leeren Steckplatzes auf die Adresse des schwachen Referenzzielobjekts gesetzt. Offensichtlich werden die Objekte in den langen und kurzen schwachen Objekttabellen nicht als Stammobjekt des betrachtet Anwendung. Der Garbage Collector sammelt keine Daten in den langen und kurzen schwachen Objekttabellen.
Sehen wir uns an, was passiert, wenn die Garbage Collection ausgeführt wird:
1. Der Garbage Collector erstellt einen erreichbaren Objektgraphen.
2 Schwache Objekttabelle: Wenn sich das Objekt, auf das in der schwachen Objekttabelle verwiesen wird, nicht im erreichbaren Objektdiagramm befindet, wird das Objekt als Müllobjekt markiert und der Objektzeiger in der kurzen Objekttabelle auf null gesetzt
3. Garbage-Collector-Scan-Beendigungswarteschlange (siehe oben): Wenn sich das Objekt in der Warteschlange nicht im Diagramm der erreichbaren Objekte befindet, wird das Objekt aus der Beendigungswarteschlange in die Freachable-Warteschlange verschoben. Zu diesem Zeitpunkt wird das Objekt als erreichbar markiert Objekt und ist kein Müll mehr
4. Der Garbage Collector scannt die lange schwache Referenztabelle. Wenn sich das Objekt in der Tabelle nicht im erreichbaren Objektdiagramm befindet (das erreichbare Objektdiagramm enthält Objekte in der Freachable-Warteschlange), setzen Sie den entsprechenden Objektzeiger in der langen Referenzobjekttabelle auf null
5. Der Garbage Collector verschiebt das erreichbare Objekt Objekt
Sobald Sie verstanden haben, wie der Garbage Collector funktioniert, ist es leicht zu verstehen, wie schwache Referenzen funktionieren. Der Zugriff auf die Target-Eigenschaft von WeakReference führt dazu, dass das System den Zielobjektzeiger in der schwachen Objekttabelle zurückgibt. Wenn er null ist, bedeutet dies, dass das Objekt recycelt wurde.
Kurze schwache Referenzen verfolgen keine Wiederauferstehungen, was bedeutet, dass der Garbage Collector prüfen kann, ob das Objekt, auf das in der schwachen Referenztabelle verwiesen wird, ein Garbage-Objekt ist, bevor er die Finalisierungswarteschlange durchsucht.
Die lange schwache Referenz verfolgt das wiederbelebte Objekt, was bedeutet, dass der Garbage Collector den Zeiger in der schwachen Referenztabelle auf Null setzen muss, nachdem er bestätigt hat, dass das Objekt recycelt wurde.
Generierung:
Wenn es um die Speicherbereinigung in .Net, C++ oder C geht, fragen sich Programmierer möglicherweise, ob es bei der Speicherverwaltung auf diese Weise zu Leistungsproblemen kommt. GC-Entwickler optimieren ständig den Garbage Collector, um seine Leistung zu verbessern. Die Generierung ist ein Mechanismus, um die Auswirkungen der Garbage Collection auf die Leistung zu reduzieren. Der Garbage Collector geht bei seiner Arbeit davon aus, dass die folgenden Aussagen wahr sind:
1. Je neuer ein Objekt ist, desto kürzer ist der Lebenszyklus des Objekts.
2. Je älter das Objekt ist, desto kürzer ist die Lebensdauer Der Zyklus des Objekts ist. Je länger
3. Neue Objekte haben normalerweise eher Referenzbeziehungen zu neuen Objekten
4. Das Komprimieren eines Teils des Heaps ist schneller als das Komprimieren des gesamten Heaps
Natürlich Viele Untersuchungen haben gezeigt, dass die oben genannten Annahmen zutreffen. Viele Verfahren sind etabliert. Sprechen wir also darüber, wie sich diese Annahmen auf die Arbeit des Garbage Collectors auswirken.
Zum Zeitpunkt der Programminitialisierung befinden sich keine Objekte auf dem verwalteten Heap. Zu diesem Zeitpunkt gehören die neu zum verwalteten Heap hinzugefügten Objekte zur Generation 0. Wie in der folgenden Abbildung dargestellt, sind Objekte der Generation 0 die jüngsten Objekte und wurden noch nie vom Garbage Collector überprüft.

Abbildung 1 Objekte der Generation 0 auf dem verwalteten Heap

Wenn nun weitere zum Heap hinzugefügt werden Objekte, die Speicherbereinigung wird ausgelöst, wenn der Heap voll ist. Wenn der Garbage Collector den verwalteten Heap analysiert, erstellt er ein Diagramm aus Garbage-Objekten (hellviolette Blöcke in Abbildung 2) und Nicht-Garbage-Objekten. Alle nicht recycelten Objekte werden an den unteren Rand des Heaps verschoben und komprimiert. Diese nicht recycelten Objekte werden zu Objekten der 1. Generation, wie in Abbildung 2 dargestellt

Abbildung 2 Managed Heap Generation 0 und 1 Objekte auf dem

Wenn mehr Objekte auf dem Heap zugewiesen werden, werden die neuen Objekte im Bereich der Generation 0 platziert. Wenn der Heap der Generation 0 voll ist, wird eine Garbage Collection ausgelöst. Zu diesem Zeitpunkt werden die überlebenden Objekte zu Objekten der Generation 1 und werden nach der Speicherbereinigung an das Ende des Heaps verschoben. Die überlebenden Objekte in den Objekten der Generation 1 werden zu Objekten der Generation 2 hochgestuft und verschoben und komprimiert. Wie in Abbildung 3 dargestellt:

Abbildung 3 Objekte der Generation 0, 1 und 2 auf dem verwalteten Heap

2代对象是目前垃圾回收器的最高代，当再次垃圾回收时，没有回收的对象的代数依然保持2.
垃圾回收分代为什么可以优化性能
如前所述，分代回收可以提高性能。当堆填满之后会触发垃圾回收，垃圾回收器可以只选择0代上的对象进行回收，而忽略更高代堆上的对象。然而，由于越年轻的对象生命周期越短，因此，回收0代堆可以回收相当多的内存，而且回收所耗的性能也比回收所有代对象要少得多。
这是分代垃圾回收的最简单优化。分代回收不需要便利整个托管堆，如果一个根对象引用了一个高代对象，那么垃圾回收器可以忽略高代对象和其引用对象的遍历，这会大大减少构建可达对象图的时间。
如果回收0代对象没有释放出足够的内存，垃圾回收器会尝试回收1代和0代堆；如果仍然没有获得足够的内存，那么垃圾回收器会尝试回收2，1，0代堆。具体会回收那一代对象的算法不是确定的，微软会持续做算法优化。
多数堆（像c-runtime堆）只要找到足够的空闲内存就分配给对象。因此，如果我连续分配多个对象时，这些对象的地址空间可能会相差几M。然而在托管堆上，连续分配的对象的内存地址是连续的。
前面的假设中还提到，新对象之间更可能存在相互引用关系。因此新对象分配到连续的内存上，你可以获得就近引用的性能优化（you gain performance from locality of reference）。这样的话很可能你的对象都在CPU的缓存中，这样CPU的很多操作就不需要去存取内存了。
微软的性能测试显示托管堆的分配速度比标准的win32 HeapAlloc方法还要快。这些测试也显示了200MHz的Pentium的CPU做一次0代回收时间可以小于1毫秒。微软的优化目的是让垃圾回收耗用的时间小于一次普通的页面错误。
使用System.GC类控制垃圾回收
类型System.GC运行开发人员直接控制垃圾回收器。你可以通过GC.MaxGeneration属性获得GC的最高代数，目前最高代是定值2.

你可以调用GC.Collect()方法强制垃圾回收器做垃圾回收，Collect方法有两个重载：

void GC.Collect(Int32 generation)

void GC.Collect()

第一个方法允许你指定要回收那一代。你可以传0到GC.MaxGeneration的数字做参数，传0只做0代堆的回收，传1会回收1代和0代堆，而传2会回收整个托管堆。而无参数的方法调用GC.Collect(GC.MaxGeneration)相当于整个回收。

在通常情况下，不应该去调用GC.Collect方法；最好让垃圾回收器按照自己的算法判断什么时候该调用Collect方法。尽管如此，如果你确信比运行时更了解什么时候该做垃圾回收，你就可以调用Collect方法去做回收。比如说程序可以在保存数据文件之后做一次垃圾回收。比如你的程序刚刚用完一个长度为10000的大数组，你不再需要他了，就可以把它设置为null然后执行垃圾回收，缓解内存的压力。
GC还提供了WaitForPendingFinalizers方法。这个方法简单的挂起执行线程，知道Freachable队列中的清空之后，执行完所有队列中的Finalize方法之后才继续执行。
GC还提供了两个方法用来返回某个对象是几代对象，他们是

Int32 GC.GetGeneration(object o);

Int32 GC.GetGeneration(WeakReference wr)

第一个方法返回普通对象是几代，第二个方法返回弱引用对象的代数。

下面的代码可以帮助你理解代的意义：

private static void GenerationDemo() {
// Let's see how many generations the GCH supports (we know it's 2)
Display("Maximum GC generations: " + GC.MaxGeneration);

// Create a new BaseObj in the heap
GenObj obj = new GenObj("Generation");

// Since this object is newly created, it should be in generation 0
obj.DisplayGeneration(); // Displays 0

// Performing a garbage collection promotes the object's generation
GC.Collect();
obj.DisplayGeneration(); // Displays 1

GC.Collect();
obj.DisplayGeneration(); // Displays 2

GC.Collect();
obj.DisplayGeneration(); // Displays 2 (max generation)

obj = null; // Destroy the strong reference to this object

GC.Collect(0); // Collect objects in generation 0
GC.WaitForPendingFinalizers(); // We should see nothing

GC.Collect(1); // Collect objects in generation 1
GC.WaitForPendingFinalizers(); // We should see nothing

GC.Collect(2); // Same as Collect()
GC.WaitForPendingFinalizers(); // Now, we should see the Finalize 
// method run

Display(-1, "Demo stop: Understanding Generations.", 0);
}
class GenObj{
public void DisplayGeneration(){
Console.WriteLine(“my generation is ” + GC.GetGeneration(this));
}

~GenObj(){
Console.WriteLine(“My Finalize method called”);
}
}

垃圾回收机制的多线程性能优化

Im vorherigen Teil habe ich den GC-Algorithmus und die Optimierung erläutert, und dann ging die Diskussion von einer Single-Threaded-Situation aus. In einem echten Programm ist es wahrscheinlich, dass mehrere Threads zusammenarbeiten und mehrere Threads gemeinsam Objekte auf dem verwalteten Heap bearbeiten. Wenn ein Thread die Garbage Collection auslöst, sollten alle anderen Threads den Zugriff auf alle referenzierten Objekte (einschließlich der Objekte, auf die in ihrem eigenen Stack verwiesen wird) aussetzen, da der Garbage Collector das Objekt verschieben und die Speicheradresse des Objekts ändern kann.
Wenn der Garbage Collector also mit dem Recycling beginnt, müssen alle Threads, die verwalteten Code ausführen, hängen bleiben. Die Laufzeit verfügt über mehrere verschiedene Mechanismen zum sicheren Anhalten von Threads, um die Garbage Collection durchzuführen. Ich werde nicht näher auf den internen Mechanismus dieses Stücks eingehen. Allerdings wird Microsoft den Garbage Collection-Mechanismus weiterhin modifizieren, um den durch die Garbage Collection verursachten Leistungsverlust zu verringern.
Die folgenden Absätze beschreiben, wie der Garbage Collector in einer Multithread-Situation funktioniert:
Codeausführung vollständig unterbrechen Wenn die Garbage Collection mit der Ausführung beginnt, alle Anwendungsthreads anhalten. Der Garbage Collector zeichnet dann die angehaltene Position des Threads in einer vom Just-in-Time-Compiler (JIT) generierten Tabelle auf. Der Garbage Collector ist dafür verantwortlich, die angehaltene Position des Threads in der Tabelle aufzuzeichnen und das Objekt aufzuzeichnen, auf das gerade zugegriffen wird wo das Objekt gespeichert ist (in Variablen, CPU-Registern usw.)
Hijacking: Der Garbage Collector kann den Stapel des Threads ändern, um die Rücksprungadresse auf eine spezielle Methode zu verweisen. Wenn die aktuell ausgeführte Methode zurückkehrt, wird diese spezielle Methode verwendet Führen Sie den Thread aus und halten Sie ihn an. Diese Art, den Ausführungspfad des Threads zu ändern, wird als Thread-Hijacking bezeichnet. Wenn die Garbage Collection abgeschlossen ist, kehrt der Thread zur zuvor ausgeführten Methode zurück.
Sicherheitspunkt: Wenn der JIT-Compiler eine Methode kompiliert, kann er an einer bestimmten Stelle einen Code einfügen, um festzustellen, ob der GC hängen bleibt. Wenn dies der Fall ist, bleibt der Thread hängen und wartet auf den Abschluss der Garbage Collection startet die Ausführung neu. Die Stellen, an denen der JIT-Compiler den prüfenden GC-Code einfügt, werden als „sichere Punkte“ bezeichnet.
Beachten Sie, dass Thread-Hijacking Threads ermöglicht, die nicht verwalteten Code ausführen, während der Garbage Collection auszuführen. Dies stellt kein Problem dar, wenn nicht verwalteter Code nicht auf Objekte im verwalteten Heap zugreift. Wenn dieser Thread derzeit nicht verwalteten Code ausführt und dann zur Ausführung von verwaltetem Code zurückkehrt, wird der Thread gekapert und setzt die Ausführung erst dann fort, wenn die Speicherbereinigung abgeschlossen ist.
Zusätzlich zu dem gerade erwähnten Zentralisierungsmechanismus verfügt der Garbage Collector über weitere Verbesserungen, um die Zuweisung und Wiederverwendung von Objektspeicher in Multithread-Programmen zu verbessern.
Synchronisationsfreie Zuweisungen: In einem Multithread-System ist der Heap der Generation 0 in mehrere Bereiche unterteilt, und ein Thread verwendet einen Bereich. Dadurch können mehrere Threads gleichzeitig Objekte zuweisen, ohne dass ein Thread ausschließlich Eigentümer des Heaps sein muss.
Skalierbare Sammlungen: Führen Sie die Serverversion der Ausführungs-Engine (MXSorSvr.dll) in einem Multithread-System aus. Der verwaltete Heap wird in mehrere verschiedene Bereiche unterteilt, einen für jede CPU. Wenn das Recycling initialisiert wird, führt jede CPU einen Recycling-Thread aus und jeder Thread beansprucht seinen eigenen Bereich zurück. Die Workstation-Version der Ausführungs-Engine (MXCorWks.dll) unterstützt diese Funktion nicht.
Recycling großer Objekte
Dieser Abschnitt wird nicht übersetzt.
Überwachung der Garbage Collection
Wenn Sie das .Net-Framework installiert haben, werden Sie es tun ein .Net CLR-Speicherelement im Leistungsindikator sein (Startmenü – Verwaltung – Leistungseintrag). Sie können ein Programm aus der Instanzliste zur Beobachtung auswählen, wie in der Abbildung unten gezeigt.

Die spezifischen Bedeutungen dieser Leistungsindikatoren sind wie folgt:

Leistungsindikatoren	Beschreibung
# Bytes in allen Heaps	Zeigt die Summe der folgenden Zählerwerte an: Zähler „Heap-Größe der Ebene 0“, Zähler der Heap-Größe „Ebene 1“, Heap-Größe der Ebene 2 Zähler und Zähler für die Heapgröße großer Objekte. Dieser Zähler gibt den aktuell auf dem Garbage-Collected-Heap zugewiesenen Speicher in Bytes an.
# GC Handles (Anzahl der GC-Handles)	Zeigt die Garbage Collection in an use Die aktuelle Anzahl der Prozesse. Unter Garbage Collection versteht man die Verarbeitung von Ressourcen außerhalb der Common Language Runtime und Hosting-Umgebung.
# Gen-0-Sammlungen (Anzahl der Level-2-Recycling)	Aus Antrag anzeigen Die Häufigkeit, mit der Objekte der Ebene 0 (d. h. die jüngsten, zuletzt zugewiesenen Objekte) seit dem Start des Programms durch Garbage Collection erfasst wurden. Garbage Collection der Stufe 0 erfolgt, wenn auf Stufe 0 nicht genügend Speicher verfügbar ist, um eine Zuweisungsanforderung zu erfüllen. Dieser Zähler wird am Ende der Garbage Collection der Ebene 0 erhöht. Die Garbage Collection auf höherer Ebene umfasst alle Garbage Collections auf niedrigerer Ebene. Dieser Zähler wird explizit erhöht, wenn eine Garbage Collection auf einer höheren Ebene (Ebene 1 oder Ebene 2) stattfindet. Dieser Zähler zeigt den zuletzt beobachteten Wert an. Der _Global_-Zählerwert ist ungenau und sollte ignoriert werden.
# Gen 1-Sammlungen (Anzahl des Recyclings der 2. Ebene)	Aus Antrag anzeigen Die Häufigkeit, mit der Objekte der Ebene 1 nach dem Start des Programms durch Garbage Collection erfasst werden. Dieser Zähler wird am Ende der Garbage Collection der Stufe 1 erhöht. Die Garbage Collection auf höherer Ebene umfasst alle Garbage Collections auf niedrigerer Ebene. Dieser Zähler wird explizit erhöht, wenn eine Garbage Collection auf höherer Ebene (Ebene 2) erfolgt. Dieser Zähler zeigt den zuletzt beobachteten Wert an. Der _Global_-Zählerwert ist ungenau und sollte ignoriert werden.
# Gen-2-Sammlungen (Anzahl der Level-2-Sammlungen)	Aus Anwendung anzeigen Die Häufigkeit, mit der Objekte der Ebene 2 seit dem Start des Programms durch Garbage Collection erfasst werden. Dieser Zähler wird am Ende einer Garbage Collection der Ebene 2 (auch als vollständige Garbage Collection bezeichnet) erhöht. Dieser Zähler zeigt den zuletzt beobachteten Wert an. Der _Global_-Zählerwert ist ungenau und sollte ignoriert werden.
# Induzierte GC (die Anzahl der verursachten GCs)	Zeigt die fällige GC an bis Die maximale Anzahl der Garbage Collections, die aufgrund expliziter Aufrufe von .Collect durchgeführt wurden. Es ist praktisch, dem Garbage Collector die Feinabstimmung der Häufigkeit seiner Sammlungen zu überlassen.
# of Pinned Objects (Anzahl der angehefteten Objekte)	Zeigt die letzte Garbage Collection an. Die Anzahl der angehefteten Objekte, die in gefunden wurden. Angeheftete Objekte sind Objekte, die der Garbage Collector nicht in den Speicher verschieben kann. Dieser Zähler verfolgt nur angeheftete Objekte im Heap, die im Garbage Collection-Prozess sind. Beispielsweise führt eine Garbage Collection der Ebene 0 dazu, dass nur angeheftete Objekte im Heap der Ebene 0 aufgelistet werden.
Anzahl der verwendeten Sink-Blöcke	Zeigt die aktuelle Anzahl der verwendeten Synchronisierungsblöcke an verwenden. Ein Synchronisationsblock ist eine objektbasierte Datenstruktur, die zum Speichern von Synchronisationsinformationen zugewiesen ist. Synchronisierte Blöcke enthalten schwache Verweise auf verwaltete Objekte und müssen vom Garbage Collector gescannt werden. Synchronisierungsblöcke sind nicht nur auf die Speicherung von Synchronisierungsinformationen beschränkt; sie können auch COM-Interop-Metadaten speichern. Dieser Zähler weist auf Leistungsprobleme im Zusammenhang mit der übermäßigen Nutzung von Synchronisierungsprimitiven hin.
# Gesamtzahl der festgeschriebenen Bytes (Gesamtzahl der festgeschriebenen Bytes)	Garbage Collection anzeigen Die Menge des virtuellen Speichers, der derzeit vom Server zugewiesen wird (in Bytes). Festgeschriebener Speicher ist der physische Speicher des in der Festplatten-Auslagerungsdatei reservierten Speicherplatzes.
# Total reservierte Bytes (Gesamtzahl der reservierten Bytes)	Garbage Collection anzeigen Die Menge des derzeit vom Server reservierten virtuellen Speichers (in Bytes). Reservierter Speicher ist virtueller Speicherplatz, der für Anwendungen reserviert ist (der aber noch keine Festplatten- oder Hauptspeicherseiten belegt hat).
% Zeit in GC (Prozentsatz der Zeit in GC)	Zeigt die Zeit seit dem letzten an Garbage Collection Der Prozentsatz der Laufzeit, die nach dem Zyklus für die Garbage Collection aufgewendet wurde. Dieser Zähler gibt normalerweise die Arbeit an, die der Garbage Collector im Auftrag der Anwendung zum Sammeln und Komprimieren von Speicher durchführt. Dieser Zähler wird nur am Ende jeder Garbage Collection aktualisiert. Dieser Zähler ist kein Durchschnittswert; sein Wert spiegelt die neuesten Beobachtungen wider.
Zugewiesene Bytes/Sekunde (Anzahl der pro Sekunde zugewiesenen Bytes)	Anzeige der Anzahl der Bytes, die pro Sekunde auf dem Garbage-Collected-Heap zugewiesen werden. Dieser Zähler wird am Ende jeder Garbage Collection aktualisiert, nicht bei jeder Zuweisung. Dieser Zähler ist kein Durchschnittswert über die Zeit; er zeigt die Differenz zwischen den in den beiden letzten Stichproben beobachteten Werten dividiert durch die Zeit zwischen den Stichproben an.
Finalization Survivors (die Anzahl der nach Fertigstellung verbleibenden Objekte)	wird angezeigt, weil es wartet auf den Abschluss. Die Anzahl der Objekte, die nach der Sammlung für die Garbage Collection zurückgehalten werden. Wenn diese Objekte Verweise auf andere Objekte behalten, bleiben diese Objekte erhalten, werden jedoch von diesem Zähler nicht gezählt. Die Zähler „Completion Memory Promoted from Level 0“ und „Completion Memory Promoted from Level 1“ stellen den gesamten aufgrund der Fertigstellung erhaltenen Speicher dar. Dieser Zähler ist kein kumulativer Zähler; er wird am Ende jeder Speicherbereinigung durch die Anzahl der Objekte aktualisiert, die nur während dieser bestimmten Sammlung überlebt haben. Dieser Zähler weist darauf hin, dass aufgrund des Abschlusses der Anwendung möglicherweise ein übermäßiger Systemaufwand entsteht.
Gen 0 Heap-Größe	Zeigt die maximale Anzahl von Bytes an, die in Ebene 0 zugewiesen werden können. Es gibt nicht die aktuelle Anzahl von Bytes an, die in Ebene 0 zugewiesen werden können. Garbage Collection der Stufe 0 findet statt, wenn die Zuweisungen seit der letzten Sammlung diese Größe überschreiten. Die Größe der Ebene 0 wird vom Garbage Collector fein abgestimmt und kann sich während der Anwendungsausführung ändern. Am Ende der Sammlung der Ebene 0 beträgt die Größe des Heapspeichers der Ebene 0 0 Byte. Dieser Zähler zeigt die Größe der Zuweisung in Bytes an, die die nächste Garbage Collection der Ebene 0 aufruft. Dieser Zähler wird am Ende der Speicherbereinigung aktualisiert (nicht bei jeder Zuordnung).
Gen 0 Promoted Bytes/Sek (geförderte Bytes/Sek. von Level 1)	Zeigt die Anzahl der Bytes pro Sekunde von Level 0 bis Level 1. Der Speicher wird hochgestuft, nachdem er von der Garbage Collection zurückgehalten wurde. Dieser Zähler ist ein Indikator für die pro Sekunde erstellten Objekte, die über einen längeren Zeitraum aufbewahrt wurden. Dieser Zähler zeigt die Differenz zwischen den in den letzten beiden Stichproben beobachteten Werten dividiert durch die Dauer des Stichprobenintervalls an.
Gen 1 Heap-Größe (Level 2 Heap-Größe)	Zeige 1. Die aktuelle Anzahl der Bytes in der Ebene; dieser Zähler zeigt nicht die maximale Größe von Ebene 1 an. Objekte werden in dieser Generation nicht direkt zugewiesen; diese Objekte werden aus früheren Garbage Collections der Ebene 0 heraufgestuft. Dieser Zähler wird am Ende der Garbage Collection aktualisiert (nicht bei jeder Zuteilung).
Gen 1 Promoted Bytes/Sek (von Level 1 hochgestufte Bytes/Sek.)	Zeigt die Anzahl der Bytes pro Sekunde, die von Level 1 auf Level 2 hochgestuft werden. Objekte, die nur deshalb hochgestuft werden, weil sie auf ihre Fertigstellung warten, sind in diesem Zähler nicht enthalten. Speicher wird hochgestuft, nachdem er aus der Garbage Collection zurückgehalten wurde. Ab Level 2 erfolgt kein Aufstieg, da es sich um das älteste Level handelt. Dieser Zähler ist ein Indikator für sehr langlebige Objekte, die pro Sekunde erstellt werden. Dieser Zähler zeigt die Differenz zwischen den in den letzten beiden Stichproben beobachteten Werten dividiert durch die Dauer des Stichprobenintervalls an.
Gen 2-Heap-Größe	Gen 2 anzeigen Die aktuelle Anzahl der Bytes im Ebene. Objekte werden in dieser Generation nicht direkt zugewiesen; diese Objekte wurden während einer vorherigen Garbage Collection der Ebene 1 heraufgestuft. Dieser Zähler wird am Ende der Garbage Collection aktualisiert (nicht bei jeder Zuteilung).
Große Objekt-Heap-Größe	Große Objekt-Heap-Größe anzeigen Die aktuelle Größe von , in Bytes. Der Garbage Collector behandelt Objekte, die größer als 20 KB sind, als große Objekte und ordnet große Objekte direkt im speziellen Heap zu. Sie werden nicht über diese Ebenen befördert. Dieser Zähler wird am Ende der Garbage Collection aktualisiert (nicht bei jeder Zuteilung).
Gesponserter Finalisierungsspeicher von Gen 0	Zeigt die Anzahl der Bytes des Speichers an Sie werden von Level 0 auf Level 1 befördert, indem Sie einfach auf den Abschluss warten. Dieser Zähler ist kein kumulativer Zähler; er zeigt den am Ende der letzten Garbage Collection beobachteten Wert an.
Geförderter Finalisierungsspeicher ab Gen 1	Zeigt die Anzahl der Bytes des Speichers an, die von Ebene 1 auf Ebene 2 hochgestuft wurden, nur weil auf den Abschluss gewartet wurde. Dieser Zähler ist kein kumulativer Zähler; er zeigt den am Ende der letzten Garbage Collection beobachteten Wert an. Wenn die letzte Garbage Collection eine Sammlung der Ebene 0 war, wird dieser Zähler auf 0 zurückgesetzt.
Geförderter Speicher ab Gen 0	Zeigt die Anzahl der Bytes des Speichers an, die danach beibehalten werden Garbage Collection und von Level 0 auf Level 1 hochgestuft. Ausgenommen von diesem Zähler sind Objekte, die nur während des Wartens auf den Abschluss angehoben werden. Dieser Zähler ist kein kumulativer Zähler; er zeigt den am Ende der letzten Garbage Collection beobachteten Wert an.
Geförderter Speicher ab Gen 1	Zeigt die Anzahl der Bytes des Speichers an, die danach beibehalten werden Garbage Collection und von Level 1 auf Level 2 befördert. Ausgenommen von diesem Zähler sind Objekte, die nur während des Wartens auf den Abschluss angehoben werden. Dieser Zähler ist kein kumulativer Zähler; er zeigt den am Ende der letzten Garbage Collection beobachteten Wert an. Wenn die letzte Garbage Collection eine Sammlung der Ebene 0 war, wird dieser Zähler auf 0 zurückgesetzt.

Diese Tabelle stammt von MSDN

Das Obige ist der Inhalt des .Net-Garbage-Collection-Mechanismusprinzips (2). Weitere verwandte Inhalte finden Sie hier. Bitte achten Sie auf PHP Chinese Net (www.php.cn)!