我曾经在某个地方读到过一个关于理想主义但“懒惰”的程序员尝试实现编程语言的共同想法。如下：-
“我知道，我会做一个易于实现和快速编写的引用计数 GCer，然后在我有时间的时候将它重新实现为真正的 GCer。”
自然，这种重新实现永远不会发生。
但是，我质疑为什么需要这样的重新实现。为什么增量和并发种类的标记和清除收集器被认为优于 Perl 5 和 Python 等语言采用的所谓过时的方法？（是的，我知道 Python 通过标记和清除收集器增强了这种方法。）
循环引用是此类讨论中提出的第一个主题。是的，这可能会很痛苦（请参阅 Perl 中的递归代码引用，并修复它涉及多个分配和引用削弱。）是的，当编码人员必须不断监视此类引用的引用时，它就不那么优雅了。
替代方案更好吗？我们可以讨论永恒的细粒度实现细节，但事实是，大多数标记和清除 GC 实现存在以下问题：-
- 资源的非确定性破坏，导致代码难以推理且过于冗长（请参阅 .NET 中的 IDispose 或许多其他语言中的 try/finally 替换。）
- 不同类别的垃圾的额外复杂性，对于短期、长期以及介于两者之间的所有内容，这种复杂性似乎是合理性能所必需的。
- 要么需要另一个线程，要么需要定期停止程序的执行以执行收集。
标记和清除的失败是否可以解决引用计数问题，这些问题可以通过弱引用来缓解？