Eine kurze Analyse der Bedeutung des GC-Garbage Collectors in Java und seiner Interaktion mit dem GC

Das Objekt wird mit new erstellt, es gibt jedoch keinen entsprechenden Löschvorgang, um den vom Objekt belegten Speicher wiederzuverwenden. Wenn wir mit der Verwendung eines Objekts fertig sind, hören wir einfach auf, auf das Objekt zu verweisen: Ändern Sie unsere Referenz so, dass sie auf ein anderes Objekt oder auf Null zeigt, oder kehren Sie von der Methode zurück, sodass die lokalen Variablen der Methode nicht mehr existieren, und machen Sie die Referenzen auf diese lokalen Variablen Variablen zeigen auf keine Objekte. Objekte, auf die nicht mehr verwiesen wird, werden als Müll bezeichnet, und der Prozess des Suchens und Recycelns dieser Objekte wird als Müllsammlung bezeichnet.

Die Java Virtual Machine verwendet Müllsammlung, um sicherzustellen, dass referenzierte Objekte im Speicher behalten werden Speicherplatz, der von Objekten belegt wird, die über keine Referenz im ausführenden Code erreichbar sind, wird freigegeben. Dies ist eine starke Garantie – wenn ein Objekt erreicht werden kann, indem man der Referenzkette ausgehend von der Stammreferenz (d. h. der Referenz, auf die im ausführenden Code direkt zugegriffen werden kann) folgt, wird das Objekt nicht recycelt.

Kurz gesagt: Wenn wir ein Objekt von keinem ausführbaren Code aus erreichen können, kann der von ihm belegte Speicherplatz zurückgewonnen werden. Beachten Sie, dass wir das Wort „kann“ verwenden, da der Garbage Collector den Speicherplatz nur dann wiederverwendet, wenn mehr Speicherplatz benötigt wird oder um einen Speicherüberlauf zu vermeiden. Das Programm wird jedoch möglicherweise ohne Speicherüberlauf oder auch dann beendet, wenn kein Speicherüberlauf vorliegt, sodass möglicherweise überhaupt keine Speicherbereinigung erforderlich ist. Wenn in allen aktuell ausgeführten Methoden nicht alle Variablen einen Verweis auf ein Objekt enthalten und ausgehend von diesen Variablen in keinem Feld oder Array-Element entlang der Referenzkette ein Verweis auf dieses Objekt gefunden wird, sagen wir einfach, dass das Objekt vorhanden ist „unerreichbar“.

Garbage Collection bedeutet, dass wir uns nie um fehlende Referenzen kümmern müssen. In Systemen, in denen der Programmierer die direkte Kontrolle darüber hat, wann Objekte gelöscht werden, kann der Programmierer ein Objekt löschen, auf das noch von anderen Objekten verwiesen wird. Wenn der Programmierer ein solches Objekt löscht, werden auch die Verweise gelöscht, die noch auf das gelöschte Objekt verweisen . baumeln, weil sie sich auf Speicherplatz beziehen, den das Betriebssystem als zuweisbar ansieht (aber tatsächlich freigegeben wurde). Das System kann diesen zuweisbaren Platz neuen Objekten zuweisen, sodass diejenigen Referenzen, die ursprünglich auf diesen Platz verwiesen, tatsächlich völlig andere Objekte erhalten, als sie erwartet hatten. In diesem Fall kann es zu unvorhersehbaren Katastrophen kommen, wenn das Programm in diesem Bereich gespeicherte Werte verwendet und sie als Objekte verarbeitet, zu denen sie nicht gehören. Die Garbage Collection löst für uns das Problem der baumelnden Referenzen, da alle Objekte, auf die noch verwiesen wird, nicht als Garbage Collection behandelt werden und der von ihnen belegte Speicherplatz nicht freigegeben werden kann. Die Garbage Collection löst auch das Problem, dass dasselbe Objekt mehrmals versehentlich gelöscht wird – ein Problem, das zu einer Katastrophe führen kann. Das Recycling von Müllobjekten erfordert kein Eingreifen von uns, aber das Recycling von Müll beansprucht bestimmte Systemressourcen. Die Erstellung und das Recycling einer großen Anzahl von Objekten kann zeitkritische Anwendungen stören. Daher müssen wir beim Entwurf solcher Systeme sorgfältig mit der Anzahl der erstellten Objekte umgehen, um die Menge des zu recycelnden Mülls zu reduzieren.

Garbage Collection garantiert nicht, dass im Speicher immer Platz für die Erstellung neuer Objekte vorhanden ist. Wenn wir beispielsweise weiterhin Objekte erstellen und sie in eine Liste aufnehmen, können keine neuen Objekte erstellt werden, wenn nicht genügend Platz zum Erstellen neuer Objekte vorhanden ist und keine nicht referenzierten Objekte vorhanden sind. Wenn wir die obige Liste Verweise auf Objekte enthalten lassen, die nicht mehr benötigt werden, würde dies zu einem Speicherverlust führen. Die Garbage Collection löst viele (aber nicht alle) Speicherzuordnungsprobleme.

Interaktion mit dem Garbage Collector

Obwohl die Java-Sprache selbst keine explizite Methode zum Entsorgen von inaktiven Objekten hat, können wir dennoch Objekte finden, die nicht mehr verwendet werden, indem wir den Garbage Collector direkt aufrufen . Mit einigen praktischen Methoden in der Runtime-Klasse und der Systemklasse können wir den Garbage Collector aufrufen, die Ausführung aller auszuführenden Finalizer anfordern oder den aktuellen Speicherstatus anzeigen:

　.public void gc F: Diese Methode fordert Java Die virtuelle Maschine verbraucht Energie für die Rückgewinnung nicht mehr verwendeter Objekte, sodass der von diesen Objekten belegte Speicher wiederverwendet werden kann.

.public void runFinalization(): Diese Methode fordert die Java Virtual Machine auf, Energie für die Ausführung der folgenden Finalizer aufzuwenden: Objekte, die als nicht erreichbar befunden wurden, deren Finalizer jedoch noch nicht ausgeführt wurden.

　„public long freememory(): Gibt die geschätzte Anzahl der verfügbaren Bytes des Systemspeichers zurück.

　·public long total Memory (): Gibt die Gesamtanzahl der Bytes des Systemspeichers zurück.

.public long maxmemoryo: Gibt die maximale Anzahl von Bytes an Systemspeicher zurück, die der Java Virtual Machine zur Verfügung stehen. Wenn das Betriebssystem keine Speichernutzungsbeschränkung für die Java Virtual Machine hat, wird Long MAX-VALUE zurückgegeben ist in Java nicht sinnvoll. Normalerweise legt die Java Virtual Machine diesen Wert über die Befehlszeile oder andere Konfigurationsoptionen fest

Um die obige Methode aufzurufen, müssen wir über die statische Methode Runtime.getRuntime einen Verweis auf das aktuelle Runtime-Objekt erhalten. Die Systemklasse unterstützt statische gc- und runFinalization-Methoden, die die entsprechenden Methoden für das aktuelle Runt-ime-Objekt aufrufen. Mit anderen Worten: Die Methoden System.gc() und Runtime.getRuntime().gc() sind gleichwertig.

Beim Aufrufen der Runtime.gc()-Methode kann der Garbage Collector möglicherweise keinen zusätzlichen Speicher freigeben, da möglicherweise kein Garbage zu sammeln ist und nicht alle Garbage Collectors bei Bedarf verfügbaren Speicher finden können. Objekte recyceln. Daher hat der Aufruf des Garbage Collectors möglicherweise keine Auswirkung. Dennoch empfiehlt es sich, die Runtime.gc()-Methode aufzurufen, bevor eine große Anzahl von Objekten erstellt wird, insbesondere bei zeitkritischen Anwendungen, bei denen der Overhead der Garbage Collection sie beeinträchtigen kann. Dies hat zwei potenzielle Vorteile: Der erste besteht darin, dass wir so viel Speicher wie möglich erhalten, bevor wir die Anwendung ausführen, und der zweite darin, dass wir die Wahrscheinlichkeit verringern können, dass der Garbage Collector während der Ausführung der Aufgabe ausgeführt wird. Die folgende Methode gibt aktiv den gesamten Speicherplatz frei, der zur Laufzeit freigegeben werden kann:

public static vo记ful1GC(){
 
Runtime rt=Runtime.getRuntime();
 
long isFree=rt.freeMemory ();
 
long wasFree;
 
do{
 
wasFree=isFree;
 
rt.runFinalization ();
 
rt.gc();
 
isFree二rt.freeMemory();
 
}while (isFree>wasFree);
 
}

Diese Methode führt eine kontinuierliche Schleife aus. Durch den kontinuierlichen Aufruf der Methoden runFinalization und gc erhöht sich der Wert von freememory weiter. Wenn die Menge an freiem Speicher nicht mehr zunimmt, endet die Schleife dieser Methode.

Normalerweise müssen wir die runFinalization-Methode nicht aufrufen, da die finalize-Methode vom Garbage Collector asynchron aufgerufen wird. In manchen Fällen, beispielsweise wenn die Ressourcen eines Elements, die durch die Finalize-Methode zurückgewonnen werden können, erschöpft sind, ist es sinnvoll, durch den Aufruf von run-Finalization so viel Finalisierung wie möglich zu erzwingen. Bedenken Sie jedoch, dass es keine Garantie dafür gibt, dass ein Objekt, das auf die Finalisierung wartet, diese Ressource verwendet, sodass runFinalization möglicherweise keine Auswirkung hat.

Der FullGc-Ansatz ist für die meisten Anwendungen zu aggressiv. In dem Sonderfall, in dem die Garbage Collection erzwungen werden muss, sammelt ein einziger Aufruf der system.gc-Methode den größten Teil, wenn nicht sogar den gesamten verfügbaren Garbage, sodass wiederholte Aufrufe die Ausgabe der Garbage Collection verringern, und zwar in vielen Systemen Diese wiederholten Anrufe sind unproduktiv.

Weitere Artikel zur Bedeutung des GC-Garbage Collectors in Java und seiner Interaktion mit GC finden Sie auf der chinesischen PHP-Website!