Objective-C 自动引用计数和垃圾回收有什么区别？

Question

通过 Xcode 4.2 中引入的新自动引用计数（ARC），我们不再需要在 Objective-C 中手动管理保留/释放。

这看起来类似于 Mac 上的 Objective-C 和其他语言中的垃圾收集。 ARC 与垃圾回收有何不同？

Answer 1

正如我在此处、ARC可以提供最好的手动内存管理和跟踪垃圾收集。它主要消除了开发人员跟踪 Objective-C 对象上的手动保留、释放和自动释放的需要，同时也避免了对垃圾收集器进程的需要，垃圾收集器进程可能会耗尽移动设备上的有限资源并导致正在运行的应用程序偶尔出现卡顿。

ARC 通过应用多年来所有 Objective-C 开发人员必须使用的规则，在编译时插入引用计数所需的适当保留和释放。这使开发人员不必自己管理。由于保留和释放是在编译时插入的，因此不需要收集器进程来不断清理内存并删除未引用的对象。

跟踪垃圾收集相对于 ARC 的一个微小优势是 ARC 不会为您处理保留周期，跟踪垃圾收集可以拾取这些内容。

关于这个主题的精彩读物来自 Apple 的 Objective-C 上的这个线程邮件列表，克里斯·拉特纳 (Chris Lattner) 说道：

GC 相对于 ARC 的主要优点是它收集保留
循环。第二个优点是“保留”的分配
“原子”因为它们是一个简单的商店。 ARC有几大
相对于 libauto GC 的优点：

1. 它具有确定性的对象回收（当对对象的最后一个强引用消失时），GC“有时会释放对象”
   稍后”。这定义了 GC 中可能存在的一类微妙错误
   由于收集器不会“在
   越野车窗户”。
2. ARC 的高水位线通常比 GC 低得多，因为对象释放得更快。
3. libauto 提供了一个脆弱的编程模型，您必须小心不要丢失写入障碍等。
4. 并非所有系统框架都是 GC 干净的，并且框架在发展过程中偶尔会出现退化。
5. ARC 不会受到假根的影响。 libauto 保守地扫描堆栈，这意味着看起来像指针的整数可以根
   对象图。
6. ARC 没有任何启动和停止您的应用程序的东西，从而导致 UI 卡顿。 libauto 在 GC 实现方面相当先进
   go 因为它不会立即停止每个线程，但它仍然会停止
   通常最终会停止所有 UI 线程。

我目前正在将手动内存管理项目以及使用 Objective-C 垃圾收集的项目迁移到 ARC。在几个 Mac 应用程序中使用垃圾收集一段时间后，我发现将这些项目迁移到 ARC 具有一些显着的优势。

Answer 2

ARC 依赖于编译时“引用”对象，这使其在低功耗模式环境（移动设备）中高效。

GC 依赖于基于运行时的“可访问”对象，这使其在多线程环境中高效。

ARC操作

将代码注入到可执行文件中，根据未使用的对象的引用计数“自动”执行。

GC 在运行时工作，因为它将检测未使用的对象图（将消除保留周期）并以不确定的时间间隔删除它们

自动引用计数的优点

• 实时、确定性地销毁对象
  未使用。
• 无后台处理。

垃圾收集的优点

• GC 可以清理整个对象图，包括保留周期。
• GC 在后台进行，因此减少了内存管理工作
  作为常规申请流程的一部分。

自动引用计数的缺点

• ARC 无法自动处理循环引用。

垃圾收集的缺点

• 因为GC发生在后台，所以对象的确切时间范围
  版本尚未确定。
• 当 GC 发生时，应用程序中的其他线程可能会被
  暂时搁置。

Answer 3

ARC 与垃圾回收有何不同？

ARC 是垃圾收集的一种形式。

您可能的意思是“ARC 和跟踪垃圾收集（如 JVM 和 .NET）之间有什么区别？”。主要区别在于 ARC 速度较慢并且存在泄漏周期。这就是 JVM 和 .NET 都使用跟踪垃圾收集器的原因。有关更多信息，请阅读引用计数和跟踪垃圾收集如何进行比较？。

Answer 4

简短而甜蜜的答案如下：

java的GC是运行时，而ARC是编译时。

GC在运行时引用对象并检查对象运行时的依赖关系。
而 ARC 在编译时附加了release、retain、autorelease调用。