ARC + 循环引用收集器与前沿 GC（例如 .NET 4.5 GC）答案

【问题标题】：ARC + cyclic references collector vs leading edge GC (say .NET 4.5 GC)ARC + 循环引用收集器与前沿 GC（例如 .NET 4.5 GC）
【发布时间】：2012-12-13 16:42:09
【问题描述】：

关于objective c ARC 机制有很多关于SO 的问题。很多人问ARC是不是要代替GC等等，甚至有讨论对于 Mac 应用程序，从 GC 移至 ARC 是合理的（如果在处理某些数据类型中的复杂引用等不需要太多工作）。

ARC 的明显缺点是完全没有任何清理循环引用的机制（编辑：循环strong 引用）。这里有一个很好很简单的关于内存泄漏的解释ARCWhat kind of leaks does automatic reference counting in Objective-C not prevent or minimize?

苹果ARC 相对于GC 优势的有趣概述。 http://lists.apple.com/archives/objc-language/2011/Jun/msg00013.html

我非常了解GC 的工作原理以及它存在什么样的问题，但是从 C#/.NET world 移动到 objective c / Cocoa 并阅读有关 ARC 的内容我仍然无法得到一件简单的事情 - 为什么没有后台机制来清理 ARC 应用程序中的循环引用。

它不需要线程挂起，是吗？所以拥有相对便宜。实施有问题吗？ GC 的轻量级版本，它可以在不暂停应用程序线程的情况下扫描堆栈、注册、构建图形、查找循环引用并释放内存，听起来很酷，不是吗？

它需要大量的计算或其他资源吗？我很难想象如何在不构建所有对象图的情况下找到循环引用，但假设这个过程是背景的并且是连续的，那么即使这样应该也可以吗？

.NET 4.5 GC (http://blogs.msdn.com/b/dotnet/archive/2012/07/20/the-net-framework-4-5-includes-new-garbage-collector-enhancements-for-client-and-server-apps.aspx) 的性能有了很大的提升，但是在 ARC 系统中拥有循环引用收集器会让第二个成为赢家吗？ ARC系统进化的下一步是什么？如果有可能并且有时会发生ARC 将具有循环引用收集器，那么它是否可以完全取代GC，或者下一代GCs（具有更好的性能）将消除ARC 系统？

UPD：请不要发布关于 weak 引用的帖子，我知道如何处理 ARC 中的循环引用，这很明显，问题是关于将循环引用收集器添加到现有 ARC 的可能性机制，因为它会像现代 GC 一样强大和通用

【问题讨论】：

Max，我想看看您如何避免循环缓冲区中的循环引用，或者说包含旅行推销员问题中所有城市和道路的图形...
为什么不呢？与 GC 相比，这是 ARC 的主要缺点
保持一个 nsarray 或 nsdictionary 具有指向图中所有节点的强指针，并在图中内部使用弱指针。弱指针是 ARC 中用于解决循环引用问题的机制。（他们摇滚）。
对我而言，ARC 或手动内存管理优于 GC 的主要优势是确定性，即我确切地知道我的对象在何时何地被销毁。
@taras，参考的主要优势。计数是更好的性能（希望如此）、更好的确定性、最佳的内存占用空间等等。 ARC 是自动的！

标签： c# objective-c garbage-collection automatic-ref-counting

【解决方案1】：

基于 C 的世界中的循环检测需要以下两件事之一：

所有对象的分配总是通过一个写屏障（可能还有一个读屏障，取决于收集器的特性）
扫描程序必须“停止世界”以在扫描周期时将内存保持在一致状态

前者是一个统一的内存模型，与直接 C 相比会产生大量开销（但可以比纯手动保留/释放更高效）。在实践中，您通常会使用某种手动引用计数（这与 ARC 编译器中的桥接机制几乎相同；CFBridgingRetain() 等）将对象从障碍世界“逃逸”到无障碍位置...)

后者对开发人员来说要容易得多，但会使性能完全不可预测，因为您永远无法知道任何给定线程何时或多长时间会停止。没有障碍，你不能真正一次只停止一个线程。

与基于 C 的环境的相对“金属”性质相比，这两者都增加了显着的开销。在基于 VM 的环境中，成本主要通过对象图连接的虚拟化与 JIT 编译后的执行路径相结合来解决，其实现的优化远远超出了 C 等预编译环境中的可能（预编译、静态可执行文件） ...不是预编译器本身）。

【讨论】：

不错的答案，但是我想请您进一步阅读第一种方法，您能否推荐一些文章？
查看 Objective-C GC 的实现。它是开源的。编译器被修改为在 GC 编译代码中发出写屏障，而编译器/收集器通过写屏障串通以了解对象指针何时转义 GC 托管内存（或堆栈内存——不同的，非常快速的优化）。过度简化。

【解决方案2】：

您的问题应该是：解决 ARC 中循环引用问题的机制是什么？

对此，答案是：弱指针。

【讨论】：

你真的读过我的问题吗？我猜不，因为它是关于将循环引用集合添加到现有 ARC 机制的可能性，以及在通用内存管理机制方面与 GC 相比如何。
是的，我读到了你的问题。它似乎是基于这样的假设，即 ARC 没有处理循环引用的机制，它确实如此。
你在哪里找到了这样的假设？问题中的第一个链接指向用弱引用回答，所以是的，我知道如何处理循环引用，并且使用 BOLD 选择主要消息。请指出我的问题中的无效假设，我将对其进行编辑
您的话：“ARC 的明显缺点是完全没有任何清理循环引用的机制。”
谢谢，我会尽快更正，我想指出强循环引用。是的，那可能是误会