Grundlagen der Garbage Collection

In der Common Language Runtime (CLR) dient der Garbage Collector als automatischer Speicher-Manager. Der Garbage Collector bietet folgende Vorteile:

• Ermöglicht es Ihnen, eine Anwendung zu entwickeln, ohne den Speicher freigeben zu müssen.

• Ordnet dem verwalteten Heap effizient Objekte zu.

• Gibt Objekte frei, die nicht mehr verwendet werden, löscht den Speicher und hält Speicher für zukünftige Belegungen bereit. Verwaltete Objekte beginnen automatisch mit einem bereinigten Inhalt, damit ihre Konstruktoren nicht jedes Datenfeld initialisieren müssen.

• Bietet Speichersicherheit, indem sichergestellt wird, dass ein Objekt den Inhalt eines anderen Objekts nicht verwenden kann.

In diesem Thema werden die wichtigsten Konzepte der Garbage Collection beschrieben. Sie enthält die folgenden Abschnitte:

• Grundlagen des Arbeitsspeichers

• Bedingungen für eine Garbage Collection

• Der verwaltete Heap

• Generationen

• Was geschieht während einer Garbage Collection

• Bearbeiten von nicht verwalteten Ressourcen

• Garbage Collection für die Arbeitsstation und Garbage Collection auf dem Server

• Gleichzeitige Garbage Collection

• Garbage Collection im Hintergrund

Grundlagen des Arbeitsspeichers

Die folgende Liste liefert eine Zusammenfassung wichtiger Arbeitsspeicherkonzepte der CLR.

• Jeder Prozess verfügt über einen eigenen separaten virtuellen Adressraum. Alle Prozesse auf demselben Computer verwenden den gleichen physischen Speicher und die gleiche Auslagerungsdatei, sofern vorhanden.

• In der Standardeinstellung verfügt jeder Prozess auf 32-Bit-Computern über einen virtuellen Adressraum von 2 GB im Benutzermodus.

• Als Anwendungsentwickler arbeiten Sie immer mit einem virtuellem Adressraum und manipulieren niemals direkt den physischen Speicher. Der Garbage Collector belegt und gibt virtuellen Arbeitsspeicher auf dem verwalteten Heap frei.

  Wenn Sie systemeigenen Code schreiben, verwenden Sie die Win32-Funktionen für die Arbeit mit dem virtuellen Adressraum. Diese Funktionen belegen und geben für Sie virtuellen Arbeitsspeicher auf systemeigenen Heaps frei.

• Virtueller Arbeitsspeicher kann sich in einem von drei Zuständen befinden:

  • Frei. Es sind keine Verweise auf den Speicherblock vorhanden, und der Speicherblock ist für eine Speicherbelegung verfügbar.

  • Reserviert. Der Speicherblock ist für die Verwendung verfügbar und kann nicht durch andere Anforderungen belegt werden. Sie können jedoch keine Daten in diesem Speicherblock speichern, bis eine Zusicherung erfolgt ist.

  • Zugesichert. Der Speicherblock ist einem physischen Speicher zugewiesen.

• Im virtuellen Adressraum können Fragmentierungen auftreten. Das bedeutet, dass freie Blöcke (Lücken) im Adressraum vorhanden sind. Wenn eine virtuelle Speicherbelegung angefordert wird, muss der Manager für virtuellen Arbeitsspeicher einen einzelnen freien Block finden, der groß genug ist, um die Belegungsanforderung zu erfüllen. Selbst wenn 2 GB freier Speicherplatz verfügbar sind, wird die Speicherbelegung, die 2 GB angefordert hat, fehlschlagen, wenn der freie Speicherplatz nicht in einem einzelnen Adressblock verfügbar ist.

• Es kann vorkommen, dass nicht mehr genügend Arbeitsspeicher zur Verfügung steht, weil der für Belegungen verfügbare virtuelle Adressraum oder der für Zusicherungen verfügbare physische Speicher nicht mehr ausreicht.

Die Auslagerungsdatei wird auch dann verwendet, wenn der tatsächliche physische Speicherbedarf insgesamt eher niedrig ist. Wenn das erste Mal eine hohe physische Speicherauslastung auftritt, muss das Betriebssystem im physischen Speicher freien Platz für die Datenspeicherung schaffen. Zu diesem Zweck werden einige Daten aus dem physischen Speicher in die Auslagerungsdatei verschoben. Für diese Daten erfolgt solange keine neue Speicherzuordnung, bis sie tatsächlich benötigt werden. Daher können Situationen entstehen, in denen auch bei einer geringen physischen Speicherauslastung Daten in der Auslagerungsdatei abgelegt sind.

Zurück nach oben

Bedingungen für eine Garbage Collection

Eine Garbage Collection wird durchgeführt, wenn eine der folgenden Bedingungen zutrifft:

• Das System verfügt über einen kleinen physikalischen Speicher.

• Der Speicher, der von Objekten belegt wird, die dem verwalteten Heap zugeordnet sind, übersteigt einen akzeptablen Schwellenwert. Dies bedeutet, dass ein Schwellenwert für die akzeptable Speicherauslastung auf dem verwalteten Heap überschritten wurde. Dieser Schwellenwert wird während der Prozessausführung kontinuierlich angepasst.

• Die GC.Collect-Methode wird aufgerufen. In fast allen Fällen müssen Sie diese Methode nicht aufrufen, da der Garbage Collector kontinuierlich ausgeführt wird. Diese Methode wird hauptsächlich für eindeutige Situationen und für Tests verwendet.

Zurück nach oben

Der verwaltete Heap

Nachdem der Garbage Collector von der CLR initialisiert wurde, belegt er ein Arbeitsspeichersegment für die Speicherung und Verwaltung von Objekten. Dieser Speicher wird als verwalteter Heap bezeichnet, im Gegensatz zu einem systemeigenen Heap im Betriebssystem.

Es gibt einen verwalteten Heap für jeden verwalteten Prozess. Alle Threads im Prozess ordnen Objekte dem gleichen Heap zu.

Um Speicher zu reservieren, ruft der Garbage Collector die Win32 VirtualAlloc-Funktion auf und reserviert jeweils ein Segment des Speichers für verwaltete Anwendungen. Zudem reserviert der Garbage Collector nach Bedarf weitere Segmente und gibt Segmente wieder für das Betriebssystem frei (nachdem alle Objekte aus diesen entfernt wurden), indem er die Win32 VirtualFree-Funktion aufruft.

Je weniger Objekte dem Heap zugeordnet sind, desto geringer ist der Arbeitsaufwand für den Garbage Collector. Wenn Sie Objekte zuordnen, verwenden Sie keine aufgerundeten Werte, die größer sind als die tatsächlichen Anforderungen. Belegen Sie z. B. kein Array von 32 Byte, wenn Sie nur 15 Byte benötigen.

Wenn eine Garbage Collection ausgelöst wird, gibt der Garbage Collector den Speicher frei, der von inaktiven Objekten belegt wird. Bei der Freigabe von Speicher werden aktive Objekte komprimiert, damit sie zusammen verschoben werden, und der inaktive Speicherplatz wird entfernt, sodass der Heap kleiner wird. Dadurch wird sichergestellt, dass Objekte, die gemeinsam zugeordnet wurden, auf dem verwalteten Heap zusammenbleiben, um ihre Lokalität beizubehalten.

Die Intrusivität (Häufigkeit und Dauer) von Garbage Collections wird bestimmt durch den Umfang der Speicherbelegungen und der Größe des beibehaltenen Speichers auf dem verwalteten Heap.

Der Heap kann als Ansammlung von zwei Heaps betrachtet werden: der große Objektheap und der kleine Objektheap.

Der große Objektheap enthält Objekte, die mindestens 85.000 Bytes groß sind. Sehr große Objekte auf dem großen Objektheap sind normalerweise Arrays. Ein Instanzobjekt ist meistens nicht sehr groß.

Zurück nach oben

Generationen

Der Heap ist in Generationen organisiert, damit er langlebige und kurzlebige Objekte behandeln kann. Die Garbage Collection tritt hauptsächlich in Verbindung mit der Freigabe kurzlebiger Objekte auf, die in der Regel nur einen kleinen Teil des Heaps belegen. Auf dem Heap gibt es drei Generationen von Objekten:

• Generation 0. Dies ist die jüngste Generation, die kurzlebige Objekte enthält. Ein Beispiel für ein kurzlebiges Objekt ist eine temporäre Variable. Die Garbage Collection tritt am häufigsten in dieser Generation auf.

  Neu zugeordnete Objekte bilden eine neue Generation von Objekten. Hierbei handelt es sich implizit um Auflistungen der Generation 0, sofern es keine großen Objekte sind. In diesem Fall gehören Sie zum großen Objektheap in einer Auflistung der Generation 2.

  Die meisten Objekte werden bei einer Garbage Collection in Generation 0 freigegeben und bleiben nicht bis zur nächsten Generation aktiv.

• Generation 1. Diese Generation enthält kurzlebige Objekte und dient als Puffer zwischen kurzlebigen Objekten und langlebigen Objekten.

• Generation 2. Diese Generation enthält langlebige Objekte. Ein Beispiel für ein langlebiges Objekt ist ein Objekt in einer Serveranwendung, das statische Daten enthält, die für die Dauer des Prozesses aktiv sind.

Garbage Collections finden für bestimmte Generationen statt, wenn die Bedingungen dies erfordern. Das Durchführen einer Sammlung für eine Generation bedeutet, dass Objekte in dieser Generation und in allen jüngeren Generationen gesammelt werden. Eine Garbage Collection für Generation 2 wird auch als vollständige Garbage Collection bezeichnet, da hierbei alle Objekte in allen Generationen (das heißt, alle Objekte im verwalteten Heap) freigegeben werden.

Beibehaltene Objekte und Höherstufungen

Objekte, die bei einer Garbage Collection nicht freigegeben werden, werden als beibehaltene Objekte bezeichnet und werden auf die nächste Generation höher gestuft. Objekte, die nach einer Garbage Collection in Generation 0 noch vorhanden sind, werden auf Generation 1 höher gestuft; Objekte, die nach einer Garbage Collection in Generation 1 noch vorhanden sind, werden auf Generation 2 höher gestuft. Objekte, die nach einer Garbage Collection Generation 2 noch vorhanden sind, bleiben in Generation 2.

Wenn der Garbage Collector erkennt, dass die Rate der beibehaltenden Objekte in einer Generation hoch ist, erhöht er den Schwellenwert von Speicherbelegungen für diese Generation, sodass bei der nächsten Garbage Collection eine beträchtliche Menge an Speicher freigegeben wird. Die CLR wägt ständig zwei Prioritäten gegeneinander ab: Zum einen soll das Workingset einer Anwendung nicht zu groß werden, und zum anderen soll die Garbage Collection nicht zu viel Zeit in Anspruch nehmen.

Kurzlebige Generationen und Segmente

Da Objekte in der Generation 0 und 1 kurzlebig sind, werden diese Generationen als kurzlebige Generationen bezeichnet.

Kurzlebige Generationen müssen das Speichersegment belegen, das als kurzlebiges Segment bezeichnet wird. Jedes neue vom Garbage Collector abgerufene Segment wird das neue kurzlebige Segment und enthält die Objekte, die nach einer Garbage Collection in Generation 0 noch bestehen. Das alte kurzlebige Segment wird das neue Segment der Generation 2.

Das kurzlebige Segment kann Objekte der Generation 2 einschließen. Objekte der Generation 2 können mehrere Segmente verwenden (so viele, wie der Prozess erfordert und für den Speicher vorgesehen sind).

Die Menge an Speicher, der bei einer kurzlebigen Garbage Collection freigegeben wird, ist auf die Größe des kurzlebigen Segments beschränkt. Der Umfang des freigegebenen Speichers ist proportional zum Speicherplatz, der von den inaktiven Objekten belegt wurde.

Zurück nach oben

Was geschieht während einer Garbage Collection

Eine Garbage Collection umfasst die folgenden Phasen:

• Eine Markierungsphase, die eine Liste aller aktiven Objekte ermittelt und erstellt.

• Eine Neuzuordnungsphase, in der die Verweise auf die zu komprimierenden Objekte aktualisiert werden.

• Eine Komprimierungsphase, in der der von den inaktiven Objekten belegte Speicherplatz freigegeben und die noch bestehenden Objekte komprimiert werden. In der Komprimierungsphase werden die Objekte, die nach einer Garbage Collection noch vorhanden sind, zum älteren Ende des Segments verschoben.

  Da Auflistungen der Generation 2 mehrere Segmente belegen können, können Objekte, die auf Generation 2 höher gestuft werden, in ein älteres Segment verschoben werden. Objekte, die sowohl Generation 1 als auch Generation 2 überlebt haben, können in ein anderes Segment verschoben werden, da sie auf Generation 2 höher gestuft werden.

  Der große Objektheap wird nicht komprimiert, da hierdurch die Speicherauslastung über einen zu langen Zeitraum zu hoch sein würde.

Der Garbage Collector bestimmt anhand folgender Informationen, ob Objekte aktiv sind:

• Stapelstämme. Vom Just-In-Time (JIT)-Compiler bereitgestellte Stapelvariablen und Stackwalker.

• Garbage Collection-Handles. Diese Handles zeigen auf verwaltete Objekte und können vom Benutzercode oder der Common Language Runtime zugeordnet werden.

• Statische Daten. Statische Objekte in Anwendungsdomänen, die auf andere Objekte verweisen können. Jede Anwendungsdomäne verfolgt die eigenen statischen Objekte.

Vor dem Start einer Garbage Collection werden alle verwalteten Threads bis auf den Thread, der die Garbage Collection ausgelöst hat, angehalten.

Die folgende Abbildung zeigt einen Thread, der eine Garbage Collection auslöst und eine Unterbrechung der Ausführung anderer Threads verursacht.

Ein Thread, der eine Garbage Collection auslöst

Zurück nach oben

Bearbeiten von nicht verwalteten Ressourcen

Wenn die verwalteten Objekte mit ihren systemeigenen Dateihandles auf nicht verwaltete Objekte verweisen, müssen Sie die verwalteten Objekte explizit freigeben, da der Garbage Collector den Speicher nur für den verwalteten Heap verfolgt.

Benutzer des verwalteten Objekts geben möglicherweise nicht die systemeigenen Ressourcen frei, die vom Objekt verwendet werden. Um die Bereinigung auszuführen, können Sie das verwaltete Objekt abschließen. Der Abschluss umfasst Bereinigungsaktionen, die Sie ausführen, wenn das Objekt nicht mehr verwendet wird. Wenn das verwaltete Objekt nicht mehr aktiv ist, führt es Bereinigungsaktionen aus, die in der Finalizer-Methode angegeben sind.

Wenn festgestellt wird, dass ein abzuschließendes Objekt inaktiv ist, wird der Finalizer des Objekts in eine Warteschlange eingereiht, damit die dazugehörigen Bereinigungsaktionen ausgeführt werden. Das Objekt selbst wird jedoch auf die nächste Generation höher gestuft. Daher müssen Sie bis zur nächsten Garbage Collection warten, die für diese Generation stattfindet (dies ist nicht notwendigerweise die nächste Garbage Collection), um zu bestimmen, ob das Objekt freigegeben wurde.

Zurück nach oben

Garbage Collection für die Arbeitsstation und Garbage Collection auf dem Server

Der Garbage Collector optimiert sich selbst und kann in einer Vielzahl von Szenarien funktionieren. Die einzige Option, die Sie basierend auf den Merkmalen der Arbeitsauslastung festlegen können, ist der Typ der Garbage Collection. Die CLR stellt mehrere Arten der Garbage Collection bereit:

• Garbage Collection für die Arbeitsstation, die für alle Clientarbeitsstationen und eigenständigen Computer vorgesehen ist. Dies ist die Standardeinstellung für das <gcServer>-Element im Laufzeitkonfigurationsschema.

  Die Garbage Collection für die Arbeitsstation kann gleichzeitig oder nicht gleichzeitig erfolgen. Die gleichzeitige Garbage Collection ermöglicht, dass verwaltete Threads während einer Garbage Collection Vorgänge fortgesetzt werden können.

  Ab .NET Framework, Version 4 wird die gleichzeitige Garbage Collection durch die Garbage Collection im Hintergrund ersetzt. 

• Garbage Collection für Server, die für Serveranwendungen vorgesehen ist, die einen hohen Durchsatz und eine hohe Skalierbarkeit erfordern.

Die folgenden Abbildungen zeigen die dedizierten Threads an, die die Garbage Collection auf einem Server ausführen.

Garbage Collection für Server

Konfigurieren der Garbage Collection

Sie können das <gcServer>-Element des Laufzeitkonfigurationsschemas verwenden, um den Typ der Garbage Collection anzugeben, der von der CLR ausgeführt werden soll. Wenn das enabled-Attribut dieses Elements auf false (die Standardeinstellung) festgelegt wird, führt die CLR die Garbage Collection für die Arbeitsstation aus. Wenn Sie das enabled-Attribut auf true festlegen, führt die CLR die Garbage Collection auf dem Server aus.

Die gleichzeitige Garbage Collection wird mit dem <gcConcurrent>-Element des Laufzeitkonfigurationsschemas angegeben. Die Standardeinstellung ist enabled. Die gleichzeitige Garbage Collection ist nur für Arbeitsstationen verfügbar und hat keine Auswirkungen auf die Garbage Collection auf dem Server.

Sie können die Garbage Collection auf dem Server auch mit nicht verwalteten Hostingschnittstellen angeben. Beachten Sie, dass ASP.NET und SQL Server automatisch die Garbage Collection auf dem Server aktivieren, wenn die Anwendung in einer dieser Umgebungen gehostet wird.

Vergleich der Garbage Collection auf Arbeitsstation und Server

Überlegungen zu Threading und Leistung der Garbage Collection auf Arbeitsstationen:

• Die Garbage Collection erfolgt auf dem Benutzerthread, der die Garbage Collection ausgelöst hat, und die Priorität bleibt unverändert. Da Benutzerthreads in der Regel mit normaler Priorität ausgeführt werden, muss der Garbage Collector (der auf einem Thread mit normaler Priorität ausgeführt wird) mit anderen Threads um CPU-Zeit konkurrieren.

  Threads, die systemeigenen Code ausführen, werden nicht angehalten.

• Die Garbage Collection für die Arbeitsstation wird immer auf einem Computer verwendet, der nur einen Prozessor besitzt, unabhängig von der <gcServer>-Einstellung. Wenn Sie angeben, dass die Garbage Collection auf dem Server erfolgen soll, verwendet die CLR die Garbage Collection für Arbeitsstationen mit deaktivierter Parallelität.

Überlegungen zu Threading und Leistung der Garbage Collection auf Servern:

• Die Garbage Collection erfolgt auf mehreren dedizierten Threads, die mit der Prioritätsebene THREAD_PRIORITY_HIGHEST ausgeführt werden.

• Für jede CPU werden ein dedizierter Thread zum Ausführen der Garbage Collection und ein Heap bereitgestellt, und die Auflistung für die Heaps findet zur gleichen Zeit statt. Jeder Heap enthält einen kleinen Objektheap und einen großen Objektheap, und auf alle Heaps kann über den Benutzercode zugegriffen werden. Objekte auf verschiedenen Heaps können aufeinander verweisen.

• Da mehrere Garbage Collection-Threads zusammenarbeiten, ist die Garbage Collection auf dem Server bei gleicher Heapgröße schneller als die Garbage Collection für die Arbeitsstation.

• Bei der Garbage Collection auf dem Server sind die Segmente häufig größer.

• Die Garbage Collection auf dem Server kann ressourcenintensiv sein. Wenn Sie z. B. 12 Prozesse haben, die auf einem Computer mit vier Prozessoren ausgeführt werden, gibt es 48 dedizierte Garbage Collection-Threads, wenn alle die Garbage Collection auf dem Server verwenden. In einer Situation mit hoher Speicherlast, wenn alle Prozesse eine Garbage Collection starten, muss der Garbage Collector 48 Threads einplanen.

Wenn Sie Hunderte von Instanzen einer Anwendung ausführen, sollten Sie erwägen, eine Garbage Collection für die Arbeitsstation mit deaktivierter gleichzeitiger Garbage Collection zu verwenden. Dies führt zu weniger Kontextwechseln, wodurch die Leistung verbessert werden kann.

Zurück nach oben

Gleichzeitige Garbage Collection

Bei der Garbage Collection für die Arbeitsstation können Sie die gleichzeitige Garbage Collection aktivieren. Diese ermöglicht die gleichzeitige Ausführung von Threads mit einem dedizierten Thread, der die Garbage Collection fast die ganze Zeit ausführt. Diese Option wirkt sich nur auf Garbage Collections in Generation 2 aus; in Generation 0 und 1 finden keine gleichzeitigen Garbage Collections statt, da sie sehr schnell beendet werden.

Dank der gleichzeitigen Garbage Collection ist die Reaktionsfähigkeit interaktiver Anwendungen besser, da die für die Garbage Collection notwendigen Pausen minimiert werden. Verwaltete Threads können weiterhin die meiste Zeit ausgeführt werden, während der Thread der gleichzeitigen Garbage Collection ausgeführt wird. Dies verkürzt die Pausen während einer Garbage Collection.

Um die Leistung zu verbessern, wenn mehrere Prozesse ausgeführt werden, deaktivieren Sie die gleichzeitige Garbage Collection.

Die gleichzeitige Garbage Collection wird auf einem dedizierten Thread ausgeführt. Standardmäßig führt die CLR die Garbage Collection für die Arbeitsstation mit aktivierter gleichzeitiger Garbage Collection aus. Dies gilt für Einzelprozessor- und für Mehrprozessorcomputer.

Die Fähigkeit, während einer gleichzeitigen Garbage Collection kleine Objekte auf dem Heap zuzuordnen, wird von den Objekten beschränkt, die im kurzlebigen Segment verbleiben, wenn eine gleichzeitige Garbage Collection gestartet wird. Sobald Sie das Ende des Segments erreichen, müssen Sie warten, bis die gleichzeitige Garbage Collection beendet wird, während verwaltete Threads, die kleine Objektzuordnungen vornehmen müssen, angehalten werden.

Die gleichzeitige Garbage Collection hat ein etwas größeres Workingset (verglichen mit der nicht gleichzeitigen Garbage Collection), da Sie während der gleichzeitigen Garbage Collection Objekte zuordnen können. Dies kann jedoch die Leistung beeinträchtigen, da die Objekte, die Sie zuordnen, Teil des Workingsets werden. Im Grunde werden bei der gleichzeitigen Garbage Collection die etwas höhere CPU- und Arbeitsspeicherlast gegen kürzere Pausen eingetauscht.

Die folgende Abbildung zeigt eine parallele Garbage Collection für einen separaten dedizierten Thread.

Concurrent garbage collection

Zurück nach oben

Garbage Collection im Hintergrund

Bei der Garbage Collection im Hintergrund werden kurzlebige Generationen (0 und 1) bei Bedarf bereinigt, während die Garbage Collection von Generation 2 ausgeführt wird. Es gibt keine Einstellung für die Garbage Collection im Hintergrund. Sie wird automatisch mit der gleichzeitigen Garbage Collection aktiviert. Die Garbage Collection im Hintergrund ist ein Ersatz für die gleichzeitige Garbage Collection. Wie auch die gleichzeitige Garbage Collection wird die Garbage Collection im Hintergrund auf einem dedizierten Thread ausgeführt und ist nur für Garbage Collections der Generation 2 zulässig.

Hinweis
Die Garbage Collection im Hintergrund ist nur in .NET Framework 4 und höheren Versionen verfügbar.

Eine Garbage Collection für kurzlebige Generationen, die während der Garbage Collection im Hintergrund stattfindet, wird als Garbage Collection im Vordergrund bezeichnet. Wenn Garbage Collections im Vordergrund stattfinden, werden alle verwalteten Threads angehalten.

Wenn eine Garbage Collection im Hintergrund ausgeführt wird und Sie genügend Objekte in Generation 0 zugeordnet haben, führt die CLR eine Garbage Collection der Generation 0 oder der Generation 1 im Vordergrund aus. Der dedizierte Thread der Garbage Collection im Hintergrund prüft häufig, ob eine Anforderung für die Garbage Collection im Vordergrund besteht. Trifft dies zu, wird die Garbage Collection im Hintergrund angehalten, damit die Garbage Collection im Vordergrund stattfinden kann. Nachdem die Garbage Collection im Vordergrund abgeschlossen wurde, werden der dedizierte Thread der Garbage Collection im Hintergrund und die Benutzerthreads fortgesetzt.

Die Garbage Collection im Hintergrund beseitigt die von der gleichzeitigen Garbage Collection auferlegten Speicherbelegungseinschränkungen, da kurzlebige Garbage Collections während der Garbage Collection im Hintergrund stattfinden können. Dies bedeutet, dass die Garbage Collection im Hintergrund inaktive Objekte in kurzlebigen Generationen entfernen und auch den Heap erweitern kann, falls dies während einer Garbage Collection in Generation 1 erforderlich ist.

Die Garbage Collection im Hintergrund ist derzeit nicht für die Garbage Collection auf dem Server verfügbar.

Zurück nach oben

Siehe auch

Weitere Ressourcen

Garbage Collection