新的自动参考计数机制是如何工作的？

3回答

慕盖茨1488219

每一个使用Object-C的新开发人员都必须学习保留、发布和自动释放对象的严格规则。这些规则甚至指定了命名约定，这意味着从方法返回的对象的保留计数。Object-C中的内存管理一旦牢记这些规则并始终如一地应用它们，就会成为第二天性，但即使是最有经验的Cocoa开发人员也会时不时地出错。使用Clang静态分析器，LLVM开发人员意识到这些规则足够可靠，他们可以构建一个工具来指出代码所采用的路径中的内存泄漏和过度释放。自动参考计数(弧)是下一个逻辑步骤。如果编译器能够识别您应该保留和释放对象的位置，为什么不让它为您插入该代码呢？僵化的、重复的任务是编译器和他们的兄弟擅长的。人类会忘记事情并犯错误，但计算机却更加一致。然而，这并不能完全免除您对这些平台上内存管理的担忧。在我的回答中，我描述了要注意的主要问题(保持周期)。这里，这可能需要你一点思考来标记弱指针。然而，与在ARC中获得的相比，这是次要的。与手动内存管理和垃圾收集相比，ARC通过减少编写/发布代码的需要，而不需要在垃圾收集环境中看到停止内存和锯齿内存配置文件，从而为您提供了这两个世界中的最佳选择。垃圾收集的唯一优势在于它处理保留周期的能力，以及原子属性赋值不贵的事实(如所讨论的)。这里)。我知道我正在用ARC实现替换我现有的所有MacGC代码。至于是否可以将其扩展到其他语言，它似乎是围绕着目标C中的参考计数系统进行的。将其应用于Java或其他语言可能很困难，但我对低级别编译器的细节还不太了解，无法在那里做出明确的声明。鉴于苹果是在LLVM中推动这一努力的人，除非另一方为此投入大量资源，否则目标-C将是第一位的。这一消息的发布震惊了WWDC的开发人员，因此人们不知道这样的事情是可以做的。随着时间的推移，它可能会出现在其他平台上，但目前它只适用于LLVM和Object-C。

0 0

30秒到达战场

弧线只是播放旧的保留/释放(MRC)，编译器确定何时调用REMENT/REST。与GC系统相比，它具有更高的性能、更低的峰值内存使用量和更可预测的性能。另一方面，用ARC(或MRC)无法实现某些类型的数据结构，而GC可以处理它们。例如，如果您有一个名为Node的类，并且节点有一个由子节点组成的NSArray，并且只有一个引用它的父节点“只使用”GC。对于ARC(以及手动引用计数)，您有一个问题。任何给定节点都将从其子节点和父节点引用。比如：A -> [B1, B2, B3]B1 -> A, B2 -> A, B3 -> A当您使用A时，一切都很好(例如通过局部变量)。当您完成它(以及B1/B2/B3)时，GC系统最终将决定从堆栈和CPU寄存器开始查看它可以找到的所有内容。它永远不会找到A，B1，B2，B3，所以它将最终完成它们，并将内存循环到其他对象中。当您使用ARC或MRC，并以A结束时，它有一个3(B1、B2和B3都引用它)，而B1/B2/B3都有一个1的引用计数(A的NSArray对每个引用持有一个引用)。因此，所有这些物体都是活的，即使没有任何东西可以使用它们。常见的解决方案是确定其中一个引用必须是弱引用(而不是对引用计数作出贡献)。这将适用于某些使用模式，例如，如果仅通过A引用B1/B2/B3，而在其他模式中则失败。例如，如果你有时会抓住B1，并期望通过父指针向上爬，找到一个弱引用的A，如果你只持有B1，A可以(通常也会)蒸发，并带B2和B3。有时候，这不是一个问题，但是一些非常有用和自然的处理复杂数据结构的方法很难在ARC/MRC中使用。因此ARC针对的是同样的问题GC目标。但是ARC在一组更有限的使用模式上工作，而不是GC，所以如果您使用GC语言(如Java)并将类似ARC的东西嫁接到它上，有些程序将不再工作(或者至少会产生大量废弃内存，并可能导致严重的交换问题或内存耗尽或交换空间不足)。您还可以说ARC将更大的优先级放在性能(或者可能是可预见性)上，而GC则将更大的优先级放在作为通用解决方案上。因此，GC的CPU/内存需求较低，性能(通常)低于ARC，但可以处理任何使用模式。对于许多常见的使用模式，弧形将工作得更好，但对于少数使用模式(有效！)使用模式，它会掉下来死掉。

0 0

湖上湖

魔法但是更具体地说，ARC的工作方式正是您对代码所做的事情(有一些细微的差别)。ARC是一种编译时技术，与GC不同，它是运行时的，会对您的性能产生负面影响。弧线将跟踪对象的引用，并根据正常规则综合保留/释放/自动释放方法。因为这样，ARC也可以在不再需要的情况下尽快发布它们，而不是纯粹为了约定而将它们扔到一个自动发布池中。其他一些改进包括对弱引用进行归零，自动将块复制到堆中，全面加速(用于自动释放池的6倍！)。有关所有这些工作的更详细讨论，请参见LLVM文档在ARC上。

0 0