关于objective c-ARC机制，SO上有很多问题。许多人问ARC是否会取代GC等。甚至有人讨论是否对于Mac应用程序，从GC转移到ARC是合理的(如果这不需要处理某些数据类型中的复杂引用等)。
ARC的明显缺点是完全缺乏任何清除循环引用的机制(编辑：循环strong引用)。以下是关于ARC内存泄漏的一个非常好且简单的解释。Objective-C中的自动引用计数不能防止或最小化什么样的泄漏？
并有趣地概述了苹果的ARC相对于其GC的优势。http://lists.apple.com/archives/objc-language/2011/Jun/msg00013.html
我很了解CCD_ 11是如何工作的，它有什么样的问题，但从C#/.NET世界转移到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吗，或者下一代GC(性能更好)将淘汰ARC系统吗？
UPD:请不要发布关于weak引用的帖子，我知道如何在ARC中处理循环引用，很明显，问题是在现有的ARC机制中添加循环引用收集器的可能性，因为它将像现代GC和一样强大和通用
在基于C的世界中进行循环检测需要两件事之一：
-
所有对象在任何地方的分配都会通过写障碍(根据收集器的特性，可能还会通过读障碍)
-
当扫描周期时，扫描仪必须"停止世界"以保持内存处于一致状态
前者是一个统一的内存模型，与直接的C相比会产生巨大的开销(但可以比纯手动保留/释放更高效)。在实践中，您通常会使用某种手动引用计数(这与ARC编译器中的桥接机制非常相似；CFBridgingRetain()等…)将对象从有障碍的世界"转义"到无障碍的位置
后者对开发人员来说要容易得多，但会使性能变得完全不可预测，因为您永远不知道任何给定线程何时停止，或停止多长时间。如果没有障碍，你不可能一次只停止一个线程。
与基于C的环境的相对"在金属上"性质相比，这两者都增加了显著的开销。在基于VM的环境中，成本在很大程度上是通过对象图连接的虚拟化与JIT编译后的执行路径相结合来解决的，JIT编译实现了远远超出预编译环境(如C)中可能实现的优化(预编译的静态可执行文件…而不是预编译器本身)。
您的问题应该是：解决ARC中循环引用问题的机制是什么？
对此，答案是：弱指针。