Angenommen, Sie haben Referenzen A -> B -> C -> D . Wenn Sie den Verweis auf B von A löschen, verbleibt eine verwaiste Kette von Objekten B -> C -> D .
Werden C und D Garbage Collected sein, obwohl es keine Möglichkeit gibt, zu ihnen zu gelangen (da es keinen Verweis auf B gibt)?
Ich stelle mir vor, dass der GC dies schlau macht und solche Abhängigkeiten auflösen wird.
Ich habe jedoch einen Blick in die Quellcode für die Klasse LinkedList und fand etwas, das dieser Annahme widerspricht. Ich habe bemerkt, dass, wenn eine Liste clear() ed ist, alle Verweise auf jeden Link explizit auf null gesetzt sind, was es zu einer Operation O(n) macht. Gibt es einen Grund / Vorteil dafür?
Das sieht ein bisschen seltsam aus. Vielleicht ist der Grund, dass die Liste explizit zerlegt wird, dass die Liste für bestehende Iteratoren und Unterlisten sowie die Elternliste gelöscht wird.
Es ist sicherlich NICHT getan, um die Garbage Collection schneller zu machen. Ein Garbage Collector durchquert die Referenzen in einem nicht erreichbaren Objekt nicht, daher macht es keinen Unterschied, sie aufzulösen.
AKTUALISIEREN
Eine neuere Version der Methode hat folgende Kommentare:
%Vor%Es scheint also zumindest in einigen Fällen einen Nutzen für die GC zu geben.
Angenommen, eine Node in einer älteren Generation enthält eine Referenz auf ein Objekt (z. B. Node oder ein Element) in einer jüngeren Generation. Diese Referenz wird zu einer "Wurzel" beim Sammeln der jüngeren Generation, wodurch das Objekt der jungen Generation beibehalten wird, selbst wenn die alte Generation Node nicht erreichbar ist. Dieser Zustand setzt sich fort, bis die ältere Generation gesammelt ist. Alte Generationen werden selten gesammelt.
Wenn Sie die Liste durchqueren und zerlegen, wird die Variable mit dem alten - & gt; Neue Referenz wird einem null zugewiesen. Die Schreibbarriere für diese Zuweisung verursacht (sofort oder zur GC-Zeit), dass die ursprüngliche Referenz nicht länger eine "Wurzel" ist. Somit kann das Objekt in der jüngeren Generation nun gesammelt werden, und es endet nicht mit einer "älteren Generation" (was die Zeit bringt, wenn diese Generation gesammelt werden muss).
Vermutlich überwiegen die GK-Vorteile die Kosten für die Wiederaufnahme der Liste ... entweder im Durchschnitt oder in Fällen, in denen die Kosten katastrophal sind.
Weitere Informationen finden Sie unter "Garbage Collection-Algorithmen für die dynamische Speicherverwaltung" von Jones und Lins. Es ist in Kapitel 7.5 in meiner (Erstausgabe) Kopie.
Im Allgemeinen ist es besser, ein Collection -Objekt wegzuwerfen und erneut zu starten, als es zur Wiederverwendung zu löschen.
Ja, C und D werden als Müll gesammelt, vorausgesetzt, dass B das Einzige ist, auf das sie verwiesen haben. Dies liegt daran, dass sie vom Diagramm aus nicht auf die Stammobjekte des Anwendungsobjektdiagramms zugreifen können.
Ich stelle mir vor, dass der Grund dafür, jeden Link auf null in der LinkedList -Implementierung zu markieren, ein Speicherleck ist. Es ist möglich, dass etwas außerhalb von LinkedList den Kopfknoten festhält. Wenn dies geschehen würde, würde es alle anderen Knoten am Leben erhalten, selbst nachdem das LinkedList gelöscht wurde.
Tags und Links java garbage-collection linked-list