Lief einen sehr einfachen Code, um zu sehen, wie Müllsammler funktionieren.
%Vor%Ich verwende ParallelGC. Ich habe GC-Ergebnisse gedruckt und hier sind die ersten (kleineren) GCs.
%Vor% youngGen kam von 14880K herunter
Allerdings ging fullHeap nur um 14872K
Bedeutet das, dass 8k in die Tenure-Generation umgezogen ist? Mein Verständnis ist, dass der GC vielleicht als instanziiert von der Klasse "a" bezeichnet wurde, die lebendig markiert und in die Besitzgeneration verschoben wurde. Ist dieses Verständnis korrekt? Ist das auch " Floating Garbage "? Überstunden wird die Tenure-Generation gefüllt und ein FullGC wird benötigt, aber es dauert eine Weile.
Auch in diesem speziellen Fall soll die gesamte kleine Sammlung gesammelt werden und im Idealfall geht nichts in die Tenure-Generation? All dies sind kurzlebige Objekte.
Sie haben eine Instanz von String am Leben, wenn der GC läuft (die starke Referenz innerhalb der while-Schleife), so dass eine davon die 8k überlebt.
In diesem Fall würde ich den String ref Floating Garbage nicht aufrufen. Floating-Müll ist, wenn ein Objekt nicht bereit war, GCed zu werden, wenn der GC es überprüfte, aber bereit war, als der GC fertig war. Ein Beispiel dafür wäre.
%Vor%Ich glaube nicht, dass Ihre Messung genau ist.
Erstens, wenn ein GC stattfindet, wird das Eden abgewischt und überlebende Objekte gehen in den Survivor-Raum. In Ihrem Fall erklärt dies, warum der YoungGen von 16448K auf 1616K geht: Diese 1616K sind die Überlebenden.
Inzwischen ist die Gesamtzahl der Heaps nach GC 1624K, was bedeutet, dass die alte Generation tatsächlich 8K Daten enthält.
Der Begriff "Floating Garbage" bezieht sich auf CMS-Sammlungen, bei denen nicht tote Objekte vom Kollektor erfasst werden. Es gilt nicht für ParallelGC.
Wie bei Ihrem Testfall werden die String-Objekte niemals in der alten Generation angezeigt. Sie werden höchstens 1 GC-Zyklus überleben und zu einem Survivor-Raum gehen und dann zurückerobert werden
Hoffe das hilft!
Tags und Links java garbage-collection