垃圾收集-孤立的LinkedList链接

Question

假设您有引用A -> B -> C -> D。当您删除对Bfrom 的引用时A，将剩下一个孤立的Objects链B -> C -> D。

将C与D被垃圾收集，即使没有办法让他们（因为有没有参考B）？

我认为GC对此很聪明，并且可以解决所有此类依赖关系。

但是，我查看了该类的源代码LinkedList，发现与此信念背道而驰。我注意到，当clear()编辑列表时，每个链接的所有引用都显式设置为null，从而使其成为一个O(n)操作。这样做有什么理由/好处吗？

Answer 1

看起来确实有些奇怪。可能是因为它明确地拆除了列表，是为了清除现有迭代器和子列表以及父列表的列表。

当然，不能加快垃圾收集的速度。垃圾收集器不会遍历不可访问对象中的引用，因此将其为null不会有任何区别。

更新

该方法的更新版本具有以下注释：

// Clearing all of the links between nodes is "unnecessary", but:
// - helps a generational GC if the discarded nodes inhabit
//   more than one generation
// - is sure to free memory even if there is a reachable Iterator

因此，看来GC至少在某些情况下是有好处的。

假设Node年龄较大的a 中包含对年龄较小的对象（例如a
Node或元素）的引用。当收集年轻一代时，该引用成为“根”，即使年轻一代Node无法访问，也导致保留了年轻一代对象。这种状态一直持续到收集到较老的一代为止。老一辈人很少被收集。

如果遍历列表并将其拆除，则包含旧->新引用的变量将分配给null。该分配的写屏障导致（立即或在GC时）原始引用不再是“根”。这样，现在就可以收集年轻一代中的对象了，并且它最终不会“持久化”到老一代中（这带来了需要收集该一代的时间）。

据推测，GC的收益要比取消选择清单的成本要高得多……无论是在平均水平上还是在成本不菲的情况下。

有关更多信息，请参阅Jones和Lins的“用于动态html" target="_blank">内存管理的垃圾收集算法”。这是我（第一版）副本中的第7.5章。

一般而言，将Collection对象扔掉并重新开始比清除对象再使用更好。