关于objective c ARC机制，有很多关于SO的问题。
许多人询问ARC是否会取代GC等等。甚至还在讨论是否
对于Mac应用程序，从ARC移至GC是合理的（如果在某些数据类型中处理复杂引用时不需要太多工作等）。
ARC的明显缺点是完全没有任何清除循环引用的机制（编辑：循环 强 引用）。
以下是ARC What 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世界转到objective c / Cocoa并阅读有关ARC的内容我仍然无法得到一个简单的事情 - 为什么没有后台机制来清除ARC中的循环引用{1}}申请 。
它不需要线程暂停，是吗？所以相对便宜。实施一个是一个问题吗？ GC 的 light版本扫描堆栈，寄存器，构建图形，查找循环引用并释放内存而不挂起应用程序线程，听起来很酷，没有？
是否需要严格的计算或其他资源？我很难想象如何在不构建所有对象图的情况下找到循环引用，但假设这个过程是背景和连续的，它应该即使以这种方式也可以吗？
.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（具有更好的性能）将消除{{ 1}}系统？
UPD：请不要发布ARC个引用，我知道如何处理ARC中的循环引用，这很明显，问题是关于添加循环引用收集器的可能性现有的ARC机制，因为它与现代GC一样强大和通用
答案 0 :(得分：8)
基于C的世界中的循环检测需要以下两种方法之一：
所有对象的分配总是经过写屏障（并且可能是读屏障，具体取决于收集器的功能）
扫描周期时，扫描仪必须“停止世界”才能将内存保持在一致状态
前者是统一的内存模型，与直接C相比会产生巨大的开销（但可以比纯手动保留/释放更高效）。在实践中，您通常会使用某种手动引用计数（从与ARC编译器中的桥接机制完全相同; CFBridgingRetain（）等）将对象从屏障世界“转移”到非屏障位置。 ...）
后者对开发人员来说要容易得多，但是性能完全不可预测，因为你永远不知道任何给定线程何时停止或持续多长时间。没有障碍，你不能一次只停止一个线程。
与基于C的环境的相对“金属”性质相比，这两者都增加了显着的开销。在基于VM的环境中，成本主要通过结合对象图连接的虚拟化与JIT编译后的执行路径相结合来实现，这种优化实现了超出C（预编译，静态可执行文件）等预编译环境的可能性。 ...而不是预编译器本身。）
答案 1 :(得分：0)
您的问题应该是：解决ARC中循环引用问题的机制是什么？
对此，答案是：弱指针。