每个接触 Objective-C
的新开发人员都必须了解何时保留、释放和自动释放对象的严格规则。这些规则甚至指定了暗示从方法返回的对象的保留计数的命名约定。一旦您牢记这些规则并始终如一地应用它们，Objective-C
中的内存管理就会成为第二天性，但即使是最有经验的 Cocoa 开发人员也会时常犯错。

借助 Clang 静态分析器，LLVM 开发人员意识到这些规则足够可靠，他们可以构建一个工具来指出代码所采用路径中的内存泄漏和过度释放。

自动引用计数(ARC)
是下一个合乎逻辑的步骤。如果编译器可以识别你应该在哪里保留和释放对象，为什么不让它为你插入代码呢？刚性、重复性的任务是编译器和他们的兄弟们擅长的。人类会忘记事情并犯错误，但计算机的一致性要高得多。

但是，这并不能完全让您不必担心这些平台上的内存管理。我在此处的回答中描述了要注意的主要问题（保留周期） ，这可能需要您稍微考虑一下以标记弱指针。但是，与您在 ARC
中获得的相比，这是次要的。

与手动内存管理和垃圾收集相比，ARC
通过减少编写保留/释放代码的需要，为您提供两全其美的体验，同时又没有在垃圾收集环境中看到的暂停和锯齿状内存配置文件。关于垃圾回收的唯一优势是它处理保留周期的能力以及原子属性分配成本低廉的事实（如这里所讨论的）。我知道我正在用 ARC 实现替换所有现有的 Mac GC 代码。

至于这是否可以扩展到其他语言，它似乎围绕着 Objective-C 中的引用计数系统。将其应用于 Java
或其他语言可能很困难，但我对低级编译器细节的了解还不够，无法在那里做出明确的陈述。鉴于 Apple 是在 LLVM
中推动这一努力的人，Objective-C 将首先出现，除非另一方为此投入大量资源。

这个震惊的开发者在 WWDC 上的揭幕，所以人们不知道可以做这样的事情。随着时间的推移，它可能会出现在其他平台上，但目前它是 LLVM 和
Objective-C 独有的。