Objekte werden unter Verwendung von neu erstellt, aber es gibt keinen entsprechenden Löschvorgang, um den vom Objekt besetzten Speicher zu recyceln. Wenn wir die Verwendung eines Objekts vervollständigen, beziehen wir uns einfach auf dieses Objekt: Ändern Sie unseren Verweis, um auf ein anderes Objekt oder auf Null zu verweisen. oder kehren Sie aus der Methode zurück, damit die lokalen Variablen der Methode nicht mehr existieren, damit die Bezugnahme auf diese lokalen Variablen auf kein Objekt hinweist. Objekte, auf die nicht mehr verwiesen wird, werden als Müll bezeichnet. Der Prozess des Findens und Recyclings dieser Objekte wird als Müllsammlung o bezeichnet
Java Virtual Machines verwenden die Müllsammlung, um sicherzustellen, dass die referenzierten Objekte im Speicher aufbewahrt werden, und befreien auch den Speicherplatz, der von Objekten besetzt ist, die durch jede Referenz im Ausführungscode nicht erreichbar sind. Dies ist eine starke Garantie dafür, dass wenn ein Objekt nicht recycelt wird, wenn die Referenzkette aus der Stammreferenz beginnt (d. H. Verweise, auf die direkt im Ausführungscode zugegriffen werden kann).
Kurz gesagt, wenn wir ein Objekt aus einem ausführbaren Code nicht erreichen können, kann der Speicherplatz recycelt werden. Beachten Sie, dass wir das Wort "Dose" verwenden, denn ob der Speicherraum recycelt wird, wird vom Müllsammler bestimmt. Im Allgemeinen wird der Müllsammler nur ausgeführt, wenn mehr Speicherplatz benötigt wird, oder um einen Speicherüberlauf zu vermeiden. Das Programm kann jedoch ohne Speicherüberlauf beenden oder selbst wenn es nicht nahe dem Speicherüberlauf liegt, sodass möglicherweise überhaupt keine Müllsammlung erforderlich ist. In allen derzeit ausgeführten Methoden, wenn alle Variablen Referenzen auf ein Objekt enthalten und aus diesen Variablen aus diesen Variablen nicht in allen Domänen oder Array -Elementen entlang der Referenzkette gefunden werden können, dann sagen wir, dass das Objekt "unerreichbar" ist.
Müllrecycling bedeutet, dass wir uns nie um baumelnde Referenzen kümmern müssen. In Systemen, in denen Programmierer direkt steuern können, wenn Objekte gelöscht werden, können Programmierer Objekte löschen, auf die sich noch andere Objekte beziehen. Wenn Programmierer solche Objekte löschen, werden Referenzen, auf die immer noch gelöschte Objekte bezogen werden, ungültig, da sie sich auf die Stille beziehen.
Das System betrachtet es für einen zuweisbaren Speicherplatz (aber tatsächlich wurde der Raum freigegeben). Das System kann diesen zuweisbaren Raum neuen Objekten zuordnen, so dass die ursprünglich auf den Raum hingewiesenen Referenzen tatsächlich zu Objekten führen, die sich völlig von dem unterscheiden, was sie erwartet haben. In diesem Fall können unvorhersehbare Katastrophen auftreten, wenn das in diesem Bereich gespeicherte Programm Werte verwendet und sie als Objekte betreibt, zu denen sie nicht gehören. Die Müllsammlung löst das Problem des Aufhängens von Referenzen für uns, da alle noch verwiesenen Objekte nicht als Müllsammlung behandelt werden, sodass der von ihnen belegte Raum nicht befreit werden kann. Die Müllsammlung löst auch das Problem, das gleiche Objekt versehentlich mehrmals zu löschen - dieses Problem kann auch zu Katastrophen führen. Das Recycling von Müllobjekten erfordert nicht unsere Intervention, aber das Recycling -Müll wird eine bestimmte Menge an Systemressourcen belegen. Die Erstellung und das Recycling einer großen Anzahl von Objekten können zeitkritische Anwendungen beeinträchtigen. Bei der Gestaltung solcher Systeme müssen wir daher sorgfältig mit der Anzahl der erstellten Objekte umgehen, um die Menge an Müll zu reduzieren, die recycelt werden sollen.
Die Müllsammlung garantiert nicht, dass der Speicher immer Platz hat, um neue Objekte zu erstellen. Wenn wir beispielsweise immer wieder Objekte erstellen und in eine Liste einfügen, können wir keine neuen Objekte mehr erstellen, wenn nicht genügend Platz vorhanden ist, um neue Objekte zu erstellen, und es gibt keine Referenzobjekte. Wenn wir die oben genannten Listenreferenzen auf Objekte aufbewahren, die nicht mehr benötigt werden, tritt ein Speicherleck auf. Die Müllsammlung löst viele (aber nicht alle) Speicherzuweisungsprobleme.
Interagieren Sie mit dem Müllsammler
Obwohl die Java -Sprache selbst keine explizite Möglichkeit hat, Leerlaufobjekte zu entsorgen, können wir immer noch Objekte finden, die nicht mehr verwendet werden, indem der Müllsammler direkt aufgerufen wird. Einige bequeme Methoden in der Laufzeitklasse und in der Systemklasse ermöglichen es uns, den Garbage Collector anzurufen, alle zu ausgeführten Finalizer auszuführen oder den aktuellen Speicherstatus anzusehen:
.Public void gc q: Diese Methode fordert die virtuelle Java -Maschine auf, Energie -Recycling -Objekte auszugeben, die nicht mehr verwendet werden, damit sie den von diesen Objekten besetzten Speicher wiederverwenden können.
.Public void runfinalisierung (): Diese Methode fordert die virtuelle Java -Maschine auf, Energie auszugeben, die die folgenden Finalizer ausführen: Objekte, die als unerreichbar befunden wurden, deren Finalizer jedoch noch nicht ausgeführt wurde.
"Public Long Freedom (): Gibt die geschätzte Anzahl verfügbarer Bytes im Systemspeicher zurück.
・ PUBLIC Long Total Memory (): Gibt die Gesamtzahl der Bytes im Systemspeicher zurück.
.Public Long MaxMemoryo: Gibt die maximale Anzahl von Bytes des Systemspeichers zurück, die der virtuellen Java -Maschine zur Verfügung stehen. Wenn das Betriebssystem keine Speichernutzungsbeschränkungen für Java -Virtual -Maschinen hat, lange. Max-Wert wird zurückgegeben. In Java gibt es keine Methode, um den maximalen Speicher des Systems festzulegen. Normalerweise setzen Java Virtual Machines diesen Wert über die Befehlszeile oder andere Konfigurationsoptionen.
Um die obige Methode aufzurufen, müssen wir über die statische Methode Runtime.getRuntime einen Verweis auf das aktuelle Laufzeitobjekt erhalten. Die Systemklasse unterstützt statische GC- und Runfinalisierungsmethoden, die die entsprechenden Methoden auf dem aktuellen Runt-I-I-Objekt aufrufen. Mit anderen Worten, System.gc () entspricht Runtime.getRuntime (). GC () Methoden.
Wenn der Müllkollektor die Runtime.gc () -Methode aufruft, kann der Müllkollektor keinen zusätzlichen Speicher freilegen, da möglicherweise nicht Müll recycelt werden kann und nicht alle Müllsammler recycelbare Objekte bei Bedarf entdecken können. Das Aufrufen des Müllsammlers hat daher möglicherweise keinen Einfluss. Das Aufrufen der Methode runtime.gc () ist jedoch wünschenswert, bevor eine große Anzahl von Objekten erstellt wird, insbesondere in zeitkritischen Anwendungen, bei denen die Müllsammlungsaufwand sie beeinflussen kann. Die Ausführung hat zwei potenzielle Vorteile: Das erste ist, dass wir vor dem Ausführen der Anwendung so viel Speicher wie möglich erhalten können, und zweitens können wir die Möglichkeit reduzieren, dass der Müllsammler während der Ausführung von Aufgaben ausgeführt wird. Die folgende Methode veröffentlicht aktiv den gesamten Raum, der zur Laufzeit veröffentlicht werden kann:
public static vo recordful1gc () {runtime rt = runTime.getRuntime (); lange isfree = rt.freememory (); langes Wasfree; do {Wasfree = isFree; rt.runfinalisierung (); rt.gc (); isfree zwei rt.freememory (); } while (isFree> wasfree); }Die Methode ist ständig geschoben, und der Wert von Freememory nimmt weiter zu, indem die Runfinalisierungs- und GC -Methoden kontinuierlich aufgerufen werden. Wenn die Menge des freien Speichers nicht mehr zunimmt, endet die Schleife der Methode.
Normalerweise müssen wir die Runfinalisierungsmethode nicht aufrufen, da die Abschlussmethode vom Müllsammler asynchron aufgerufen wird. In einigen Fällen ist es beispielsweise, wenn eine Ressource, die durch die Abschlussmethode recycelt werden kann, erschöpft ist, nützlich, so viele Kündigungen wie möglich durch Aufrufen von Runfinalisierung durchzusetzen. Denken Sie jedoch daran, dass wir nicht garantieren können, dass jedes Objekt, das darauf wartet, beendet zu werden, diese Ressource verwendet, sodass die Runfinalisierung möglicherweise keinen Einfluss hat.
Die FullGC -Methode scheint für die meisten Anwendungen zu radikal zu sein. In besonderen Fällen, in denen die Müllsammlung erforderlich ist, ist es die überwiegende Mehrheit davon. Daher reduzieren wiederholte Anrufe die Ausgangsrate der Müllsammlung, und in vielen Systemen sind diese wiederholten Anrufe ausgabelos.