memory-leaks - 与编译时ARC相比，运行时GC有何优势？

Question

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

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

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

Answer 1

这里涉及很多折衷，这是一个复杂的话题。不过，这是最重要的:

GC专家:

跟踪垃圾收集器可以处理对象图中的循环。自动引用计数将泄漏内存，除非通过删除引用或弄清楚图形的哪个边应较弱来手动中断循环。实际上，这是引用计数应用程序中的一个普遍问题。

通过并发执行工作，通过批处理工作，通过推迟工作以及通过不弄乱热循环中涉及引用计数的缓存，跟踪垃圾收集器实际上(在吞吐量方面)比引用计数要适度更快。

复制收集器可以压缩堆，回收碎片化的页面以减少足迹

ARC优点:

因为当引用计数达到0时对象破坏立即发生，所以对象生存期可用于管理非内存资源。对于垃圾回收，生存期是不确定的，因此这是不安全的。

收集工作通常更分散，导致停顿时间更短(如果取消分配较大的对象子图，仍然有可能获得停顿)

因为内存是同步收集的，所以不可能通过分配速度超过清理速度来“超出收集器”。当VM分页生效时，这一点尤其重要，因为在某些退化的情况下，GC线程会撞到已分页的页面，而远远落后于此。

在相关说明中，跟踪垃圾收集器必须遍历整个对象图，这将强制进行不必要的分页(有类似https://people.cs.umass.edu/~emery/pubs/f034-hertz.pdf的缓解方法，但并未广泛部署)

如果要达到最大吞吐量，则跟踪垃圾收集器通常需要比引用计数更多的“暂存空间”

我个人认为，在大多数情况下，真正重要的只有两点是:

ARC不收集周期

GC没有确定的生存期

我认为这两个问题都是破坏交易的因素，但是在没有更好的主意的情况下，您只需要选择哪个听起来更恐怖的问题对您来说更糟即可。