Mehr über den Garbage Collector

Hallo! In der letzten Lektion haben wir zunächst den in Java integrierten Garbage Collector kennengelernt und eine ungefähre Vorstellung davon bekommen, wie er funktioniert. Es arbeitet im Hintergrund, während Ihr Programm ausgeführt wird, und sammelt unnötige Objekte, die später gelöscht werden. Dadurch wird Speicher frei, der in Zukunft zum Erstellen neuer Objekte verwendet werden kann. In dieser Lektion besprechen wir ausführlicher, wie es funktioniert. Wie und wann wird beispielsweise ein Objekt überflüssig? Und wie findet der Müllsammler das heraus? Dies sind Fragen, die wir in der heutigen Lektion beantworten werden :) Die Lektion wird eher einem Überblick ähneln: Sie müssen dieses Material nicht auswendig lernen. Die Absicht besteht hauptsächlich darin, Ihre Vorstellung davon zu erweitern, wie Speicher und Garbage Collector funktionieren. Lesen Sie es also einfach durch und finden Sie etwas Neues für sich :) Los geht's! Als Erstes müssen Sie bedenken, dass der Garbage Collector parallel zu Ihrem Programm arbeitet. Es ist nicht Teil Ihres Programms. Er läuft separat (in der letzten Lektion haben wir ihn mit einem Roboterstaubsauger verglichen). Aber das war nicht immer so. Früher wurde die Garbage Collection im selben Thread wie Ihr Programm durchgeführt. Nach einem bestimmten Zeitplan (alle paar Minuten) prüft der Garbage Collector, ob unerwünschte Objekte im Programm vorhanden sind. Das Problem bestand darin, dass das Programm während dieser Überprüfung und Speicherbereinigung hängen blieb (nicht ausgeführt wurde). Stellen Sie sich vor, Sie sitzen in Ihrem Büro bei der Arbeit. Doch dann kommt die Putzfrau, um die Böden zu waschen. Sie vertreibt Sie fünf Minuten lang von Ihrem Computer und Sie warten, bis sie mit dem Putzen fertig ist. Während dieser Zeit können Sie nicht arbeiten. So funktionierte die Garbage Collection früher :) Dieser Mechanismus wurde später geändert und jetzt läuft der Garbage Collector im Hintergrund. die Arbeit des Programms selbst nicht behindern. Sie wissen bereits, dass ein Objekt stirbt, wenn es keine Referenzen mehr hat. In Wirklichkeit,Der Garbage Collector zählt keine Objektreferenzen . Erstens kann dies lange dauern. Zweitens ist es nicht sehr effektiv. Schließlich können Objekte aufeinander verweisen! Die Abbildung zeigt ein Beispiel, bei dem drei Objekte aufeinander verweisen, aber niemand anderes auf sie verweist. Mit anderen Worten: Der Rest des Programms benötigt sie nicht. Würde der Garbage Collector einfach Referenzen zählen, würden diese 3 Objekte nicht gesammelt und der Speicher nicht freigegeben (es gibt Referenzen darauf!). Wir können dies mit einem Raumschiff vergleichen. Während des Fluges beschließen die Astronauten, die Liste der für Reparaturen verfügbaren Ersatzteile zu prüfen. Unter anderem finden sie ein Lenkrad und Pedale aus einem gewöhnlichen Auto. Offensichtlich werden sie hier nicht benötigt und beanspruchen unnötig Platz (obwohl diese beiden Teile miteinander verbunden sind und einige Funktionen haben). Aber im Raumschiff sind sie nutzloser Müll, der entsorgt werden sollte. Dementsprechend wurde in Java die Entscheidung getroffen, Müll nicht auf Basis der Referenzzählung zu sammeln, sondernerreichbar und unerreichbar . Wie stellen wir fest, ob ein Objekt erreichbar ist? Es ist alles einfach genial. Ein Objekt ist erreichbar, wenn es von einem anderen erreichbaren Objekt referenziert wird. Somit erhalten wir eine „Kette der Erreichbarkeit“. Es beginnt mit dem Programmstart und dauert für die Dauer des Programms an. Es sieht ungefähr so ​​aus: Der Pfeil in der Abbildung zeigt den ausführbaren Code unseres Programms an. Der Code (zum Beispiel die main()Methode) erstellt Referenzen auf Objekte. Diese Objekte können auf andere Objekte verweisen, diese Objekte auf noch andere und so weiter. Dies bildet eine Referenzkette. Wenn Sie die Kette von einem Objekt bis zur „Stammreferenz“ (die direkt im ausführbaren Code erstellte) verfolgen können, gilt sie als erreichbar. Solche Objekte sind im Bild schwarz markiert. Ein Objekt ist jedoch nicht erreichbar, wenn das Objekt aus dieser Kette herausfällt, dh keine der Variablen im aktuell ausgeführten Code verweist auf es und es kann nicht über die „Referenzkette“ erreicht werden. In unserem Programm sind zwei solcher Objekte rot markiert. Beachten Sie, dass diese „roten“ Objekte aufeinander verweisen. Aber wie bereits erwähnt, zählt der moderne Garbage Collector von Java keine Referenzen. Es bestimmt, ob ein Objekt erreichbar oder nicht erreichbar ist. Dadurch werden die beiden roten Objekte in der Abbildung erfasst. Schauen wir uns nun den gesamten Prozess von Anfang bis Ende an. Dabei werden wir auch sehen, wie der Speicher in Java angeordnet ist :) Alle Java-Objekte werden in einem speziellen Speicherbereich namens Heap gespeichert . Im alltäglichen Sprachgebrauch ist ein Haufen meist ein Berg von Gegenständen, in dem alles vermischt ist. Aber das ist nicht der Heap in Java. Seine Struktur ist sehr logisch und vernünftig. Irgendwann stellten Java-Programmierer fest, dass alle ihre Objekte in zwei Typen unterteilt werden konnten: einfache Objekte und „langlebige Objekte“.. „Langlebige Objekte“ sind Objekte, die viele Runden der Speicherbereinigung überstanden haben. Sie leben normalerweise bis zum Ende des Programms. Am Ende wurde der gesamte Heap, in dem alle Objekte gespeichert sind, in mehrere Teile aufgeteilt. Der erste Teil hat einen schönen Namen: Eden(aus dem biblischen „Garten Eden“). Dieser Name ist passend, denn hier landen Objekte nach ihrer Erstellung. Dies ist der Teil des Speichers, in dem neue Objekte erstellt werden, wenn wir das Schlüsselwort new verwenden. Es können viele Objekte erstellt werden. Wenn in diesem Bereich nicht mehr genügend Speicherplatz vorhanden ist, beginnt eine erste „schnelle“ Speicherbereinigung. Wir müssen sagen, dass der Müllsammler sehr clever ist. Es wählt einen Algorithmus basierend darauf, ob der Heap mehr Müll oder mehr lebende Objekte enthält. Wenn fast alle Objekte Müll sind, markiert der Collector die lebenden Objekte und verschiebt sie in einen anderen Speicherbereich. Anschließend wird der aktuelle Bereich vollständig geräumt. Wenn nicht viel Müll vorhanden ist und der Haufen hauptsächlich aus lebenden Objekten besteht, markiert der Sammler den Müll, räumt ihn weg und packt die anderen Objekte zusammen. Wir sagten "ein Überlebensraum . Ein Überlebensraum wiederum ist in Generationen eingeteilt . Jedes Objekt gehört zu einer bestimmten Generation, abhängig davon, wie viele Runden der Speicherbereinigung es überstanden hat. Wenn ein Objekt eine Garbage-Collection-Runde überstanden hat, befindet es sich in „Generation 1“; wenn 5, dann „Generation 5“. Eden und ein Überlebensraum bilden zusammen einen Bereich namens „ Junge Generation“ . Zusätzlich zur jungen Generation verfügt der Heap über einen weiteren Speicherbereich, der als alte Generation bezeichnet wird. Genau in diesem Bereich landen langlebige Objekte, die viele Runden der Müllabfuhr überstanden haben. Es hat Vorteile, sie von allen anderen zu trennen. Eine vollständige Garbage Collection wird nur dann durchgeführt, wenn die alte Generation voll ist, dh das Programm enthält so viele langlebige Objekte, dass nicht genügend Speicher vorhanden ist. Dieser Prozess umfasst mehr als einen Speicherbereich. Im Allgemeinen handelt es sich dabei um alle von der Java-Maschine erstellten Objekte. Dies erfordert natürlich viel mehr Zeit und Ressourcen. Genau aus diesem Grund wurde die Entscheidung getroffen, langlebige Gegenstände getrennt aufzubewahren. Eine „schnelle Müllsammlung“ wird durchgeführt, wenn in anderen Bereichen der Platz knapp wird. Dies betrifft nur einen Bereich, was die Arbeit schneller und effizienter macht. Wenn schließlich auch der Bereich für langlebige Objekte vollständig gefüllt ist, Die vollständige Garbage Collection wird ausgelöst. Somit nutzt der Sammler das „schwerste“ Werkzeug nur dann, wenn es unmöglich ist, ihm auszuweichen. Hier ist eine visuelle Darstellung der Heap-Struktur und der Garbage Collection: