Vorwort
GC (Garbage Collection) ist eine unvermeidliche Hürde beim Erlernen von JVM Studieren Sie GC systematisch.
Bevor wir etwas tun, müssen wir wissen, warum wir es tun. Dies bezieht sich nicht nur auf GC, sondern gilt auch für unser tägliches Lernen und Leben. Nur wenn Sie wissen, warum, können Sie gefahrlos kämpfen.
(Empfohlenes Video: Java-Video-Tutorial)
Lassen Sie uns zunächst verstehen, warum es einen GC gibt und welche Rolle GC in der JVM spielt.
Warum gibt es einen GC?
Studenten, die C++ verwendet haben, wissen möglicherweise, dass der von einem Objekt belegte Speicher bis zum Ende des Programms belegt ist und erst dann zugewiesen werden kann wird explizit an andere Objekte weitergegeben. Wenn wir diese nutzlosen Objekte nicht manuell löschen, wird der Speicher bald voll sein. In der JVM spielt er die Rolle eines Scavengers. Er kann uns dabei helfen, festzustellen, welche Objekte nutzlos sind und wie wir vorgehen die Strategien, die die Speichergenerierung und Speicherzuweisung bestimmen**.
Einige Studenten fragen sich vielleicht, warum wir GC lernen müssen, da unsere JVM die GC-Arbeit für uns erledigt. Ist es nicht besser, alles der JVM zu überlassen? Natürlich kümmern wir uns in unserem täglichen Leben im Allgemeinen nicht um einige Details von GC, aber wenn wir auf Speicherlecks, Speicherüberläufe und Engpässe bei hoher Parallelität stoßen, müssen wir GC bearbeiten und detailliertere Analysen durchführen.
Speicherleck: bezieht sich auf den dynamisch zugewiesenen Heap-Speicher im Programm, der nicht freigegeben wird oder aus irgendeinem Grund nicht freigegeben werden kann, was zu einer Verschwendung von Systemspeicher, einer Verlangsamung des Programms oder sogar Systemabstürzen führt und andere schwerwiegende Folgen.
Speicherüberlauf: Es gibt nicht wiederherstellbaren Speicher im Anwendungssystem oder es wird zu viel Speicher verwendet, was letztendlich dazu führt, dass der vom Programm für die Ausführung verwendete Speicher größer ist als der maximal verfügbare Speicher.
Die Frage ist nun, wir müssen die Müllabfuhr durchführen, zuerst müssen wir wissen, wo der Müll ist
Wo ist der Müll
Vorne Wir haben über den Laufzeitspeicherbereich von JVM gesprochen und wissen, dass Threads in Thread-exklusive Bereiche und Thread-gemeinsam genutzte Bereiche unterteilt werden können. Der Speicherlebenszyklus des Thread-exklusiven Bereichs (Programmzähler, virtueller Maschinenstapel). , lokaler Methodenstapel) ist mit dem Thread konsistent, und die in diesen Bereichen zugewiesene Speichergröße hängt von der Größe der Klasse ab. Mit anderen Worten, wenn unsere Klassenstruktur festgelegt ist, ändert sich dieser Teil des Speichers nicht Wenn die Methode oder der Thread endet, wird der Speicher natürlich recycelt.
Der Heap-Speicher und der Methodenbereich im gemeinsam genutzten Thread-Bereich sind unterschiedlich. Der im Heap-Speicher und im Methodenbereich verwendete Speicher kann nicht ermittelt werden Kompilierung, da unterschiedliche Implementierungen einer Schnittstelle und einer Methode Der Code, der von verschiedenen Steuerbedingungszweigen ausgeführt wird, kann völlig unterschiedlich sein. Wir wissen nur, welche Objekte zur Laufzeit erstellt werden, und unser GC konzentriert sich auf diesen Teil der Erinnerung.
Zum Beispiel: Wenn es sich bei der JVM um ein Auto handelt, ist der Thread-Exklusivbereich wie bei Teilen. Die Lebensdauer dieser Teile ist grundsätzlich bekannt, wenn sie das Werk verlassen, und der Thread-Shared-Bereich ist wie Benzin Benzin hängt mit der Route zusammen, die wir nehmen, daher machen wir uns Sorgen, dass sich dieser Teil dynamisch ändern wird, beispielsweise wie man kraftstoffeffizienter fährt~
Dieser Artikel stammt von der chinesischen PHP-Website, Java-TutorialSpalte, willkommen zum Lernen!
Das obige ist der detaillierte Inhalt vonVerstehen Sie das Konzept von GC in JAVA in 3 Minuten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!