Memory leaks 运行时GC相对于编译时ARC的优势是什么？

一些较新的语言正在其编译器中实现ARC（Swift和Rust等）。据我所知，这实现了与运行时GC相同的功能（减轻了程序员手动解除分配的负担），同时大大提高了效率

我知道ARC可能会成为一个复杂的过程，但随着现代垃圾收集器的复杂性，实现ARC似乎不再复杂。然而，仍然有很多语言和框架使用GC进行内存管理，甚至针对系统编程的Go语言也使用GC

---

我真的不明白为什么GC比ARC更可取。我在这里遗漏了什么吗？

这里涉及到一系列权衡，这是一个复杂的话题。不过，这里有几个大问题：

总承包商专业人员：

• 跟踪垃圾收集器可以处理对象图中的循环。自动引用计数将泄漏内存，除非通过删除引用或计算图形的哪条边应该是弱的来手动中断周期。这在引用计数应用程序中是一个非常常见的问题
• 跟踪垃圾收集器实际上可以比引用计数稍微快一些（就吞吐量而言），方法是并行地执行工作、批处理工作、延迟工作，以及不破坏高速缓存（在热循环中接触引用计数）
• 复制收集器可以压缩堆，回收碎片页面以减少占用空间

ARC专业人士：

• 由于对象销毁在引用计数达到0时立即发生，因此对象生存期可用于管理非内存资源。对于垃圾收集，生命周期是不确定的，因此这是不安全的
• 收集工作通常更分散，导致暂停时间更短（如果取消分配对象的大型子图，仍有可能获得暂停时间）
• 因为内存是同步收集的，所以不可能通过分配比清理更快的内存来“超过收集器”。当VM分页开始发挥作用时，这一点尤其重要，因为存在GC线程命中已被分页的页面并远远落后的退化情况
• 与此相关的一点是，跟踪垃圾收集器必须遍历整个对象图，这会强制执行不必要的页面插入（类似的情况有缓解措施，但没有广泛部署）
• 如果跟踪垃圾收集器想要达到其全部吞吐量，则通常需要比引用计数更多的“暂存空间”

我个人的看法是，在大多数情况下，唯一真正重要的两点是：

• ARC不收集循环
• GC没有确定的生命周期

---

我觉得这两个问题都是破坏者，但如果没有更好的想法，你只需要选择哪个可怕的问题听起来更糟糕。

对于跟踪GC和引用计数的一般概念比较，本文“垃圾收集的统一理论”展示了如何将它们视为彼此的严格对偶。对每种方法的各种优化和调整只会让你沿着连接它们的光谱前进：哦，是的，我喜欢那篇文章：D谢谢你链接它