Objective-C中的自动引用计数不会阻止或最小化哪种泄漏？ [英] What kind of leaks does automatic reference counting in Objective-C not prevent or minimize?

问题描述

在Mac和iOS平台上，内存泄漏通常是由未发布的指针引起的。传统上，检查您的分配，副本和保留一直是最重要的，以确保每个都有相应的发布消息。

In the Mac and iOS platforms, memory leaks are often caused by unreleased pointers. Traditionally, it has always been of utmost importance to check your allocs, copies and retains to make sure each has a corresponding release message.

Xcode 4.2附带的工具链介绍使用最新版本的 LLVM编译器自动引用计数（ARC），通过让编译器对内存进行内存管理，完全解决了这个问题为你。这非常酷，它确实减少了许多不必要的，平凡的开发时间，并防止了很多粗心的内存泄漏，这些泄漏很容易通过适当的保留/释放平衡来修复。当您为Mac和iOS应用启用ARC时，甚至需要对自动释放池进行不同的管理（因为您不应再分配自己的 NSAutoreleasePool ）。

The toolchain that comes with Xcode 4.2 introduces automatic reference counting (ARC) with the latest version of the LLVM compiler, that totally does away with this problem by getting the compiler to memory-manage your stuff for you. That's pretty cool, and it does cut lots of unnecessary, mundane development time and prevent a lot of careless memory leaks that are easy to fix with proper retain/release balance. Even autorelease pools need to be managed differently when you enable ARC for your Mac and iOS apps (as you shouldn't allocate your own NSAutoreleasePools anymore).

但其他内存泄漏是什么不阻止我仍需要注意？

But what other memory leaks does it not prevent that I still have to watch out for?

作为奖励，Mac OS X和iOS上的ARC与Mac OS X上的垃圾收集有什么区别？

As a bonus, what are the differences between ARC on Mac OS X and iOS, and garbage collection on Mac OS X?

推荐答案

您仍需要注意的与内存相关的主要问题是保留周期。当一个对象具有指向另一个对象的强指针但目标对象具有返回原始对象的强指针时，会发生这种情况。即使删除了对这些对象的所有其他引用，它们仍将保持彼此并且不会被释放。这也可以间接地通过一系列对象发生，这些对象可能在链中的最后一个引用回到较早的对象。

The primary memory-related problem you'll still need to be aware of is retain cycles. This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original. Even when all other references to these objects are removed, they still will hold on to one another and will not be released. This can also happen indirectly, by a chain of objects that might have the last one in the chain referring back to an earlier object.

由于这个原因， __ unsafe_unretained 和 __ weak 存在所有权限定符。前者不会保留它指向的任何对象，但会留下该对象消失的可能性并指向坏内存，而后者不保留对象并在其目标被释放时自动将其自身设置为nil。在这两者中， __弱通常在支持它的平台上首选。

It is for this reason that the __unsafe_unretained and __weak ownership qualifiers exist. The former will not retain any object it points to, but leaves open the possibility of that object going away and it pointing to bad memory, whereas the latter doesn't retain the object and automatically sets itself to nil when its target is deallocated. Of the two, __weak is generally preferred on platforms that support it.

您可以将这些限定符用于代理，您不希望该对象保留其委托并可能导致循环。

You would use these qualifiers for things like delegates, where you don't want the object to retain its delegate and potentially lead to a cycle.

另外两个与内存相关的重要问题是Core Foundation的处理使用 malloc（）为 char * 等类型分配的对象和内存。 ARC不管理这些类型，只管理Objective-C对象，因此您仍需要自己处理它们。 Core Foundation类型可能特别棘手，因为有时它们需要桥接到匹配的Objective-C对象，反之亦然。这意味着当在CF类型和Objective-C之间进行桥接时，需要从ARC来回传输控制。添加了一些与此桥接相关的关键字，Mike Ash对他冗长的ARC写作。

Another couple of significant memory-related concerns are the handling of Core Foundation objects and memory allocated using malloc() for types like char*. ARC does not manage these types, only Objective-C objects, so you'll still need to deal with them yourself. Core Foundation types can be particularly tricky, because sometimes they need to be bridged across to matching Objective-C objects, and vice versa. This means that control needs to be transferred back and forth from ARC when bridging between CF types and Objective-C. Some keywords related to this bridging have been added, and Mike Ash has a great description of various bridging cases in his lengthy ARC writeup.

除此之外，还有其他一些不太频繁，但是仍有潜在问题的案例，发布的规范详细介绍。

In addition to this, there are several other less frequent, but still potentially problematic cases, which the published specification goes into in detail.

基于保持对象的大部分新行为，只要有强大的指针，就像Mac上的垃圾收集一样。但是，技术基础是非常不同的。这种内存管理方式不依赖于定期运行的垃圾收集器进程来清理不再被指向的对象，而是依赖于我们在Objective-C中需要遵守的严格保留/释放规则。

Much of the new behavior, based on keeping objects around as long as there is a strong pointer to them, is very similar to garbage collection on the Mac. However, the technical underpinnings are very different. Rather than having a garbage collector process that runs at regular intervals to clean up objects no longer being pointed to, this style of memory management relies on the rigid retain / release rules we all need to obey in Objective-C.

ARC只需要多年来我们必须执行的重复内存管理任务，并将它们卸载到编译器中，这样我们再也不用担心它们了。这样，您就没有垃圾收集平台上遇到的暂停问题或锯齿内存配置文件。我在垃圾收集的Mac应用程序中经历过这两种情况，并且我很想知道它们在ARC下的行为。

ARC simply takes the repetitive memory management tasks we've had to do for years and offloads them to the compiler so we never have to worry about them again. This way, you don't have the halting problems or sawtooth memory profiles experienced on garbage collected platforms. I've experienced both of these in my garbage collected Mac applications, and am eager to see how they behave under ARC.

有关垃圾收集与ARC的更多信息，请参阅 Chris Lattner在Objective-C邮件列表中的这个非常有趣的回复，他列出了ARC优于Objective-C 2.0垃圾收集的许多优点。我遇到了他描述的几个GC问题。

For more on garbage collection vs. ARC, see this very interesting response by Chris Lattner on the Objective-C mailing list, where he lists many advantages of ARC over Objective-C 2.0 garbage collection. I've run into several of the GC issues he describes.

这篇关于Objective-C中的自动引用计数不会阻止或最小化哪种泄漏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！