在Objective-C的ARC状况下，什么样的内存泄漏是没法避免或者减小的？

以前写了一个关于__unsafe_unretained特殊标识符讲解的翻译，其中也讲到了关于ARC状况下内存泄漏的问题，这片文章就是对以前问题的一个翻译讲解。

点击进入StackOverFlow问答页

1、问题

问题

问题翻译

在Mac和iOS平台上，未被释放的指针常常会致使内存泄漏。传统状况下，检查你的alloc、copy和retain来肯定每一个都有相对应的释放常常会变得极为重要。

伴随着Xcode 4.2到来的数据链，介绍了来自于最新一个版本的LLVM编译器的自动引用计数（ARC），经过让编译器对内存进行管理，彻底能够解决这个问题。这是很是酷的，而且它确实减小了没必要要的、无用的开发时间，并防止不少不当心的内存泄漏，这些内存泄漏运用适当的保留或者释放会很容易修复。当你为Mac和iOS应用启用ARC时，即便自动释放池也须要进行不一样的管理（由于你不该该分配本身的NSAutoreleasePools了）。

可是还有什么其余没有被阻止的内存泄漏我还须要注意么？

做为额外的，Mac OS X和iOS上的ARC，以及Mac OS X上的内存回收有什么区别？

2、回答

回答

回答翻译

您仍然须要注意的主要内存相关问题是循环引用。这种状况出如今当一个对象有一个强引用指针到另外一个对象，可是目标指针也有一个强引用的指针指向最初的对象。å即便删除对这些对象的全部其余引用，他们仍然互相持有对方而且不会被释放。这也可能间接发生，经过可能在链中的最后一个对象引用回到较早对象的对象链。

这就是__unsafe_unretained和__weak全部权限定词存在的缘由。前者不会保留任何它指向的对象，可是留下该对象消失和指向错误内存的可能性，然后者不保留对象，而且当其目标被释放时自动将其设置为nil。二者之中，__weak在支持它的平台上一般是首选的。

你可使用这些限定符来执行像代理一类的事情，这种状况下你不但愿对象保留其委托对象而且可能致使循环引用。

另外几个重要的内存相关问题是处理Core Foundation对象和使用malloc()分配像类型为char *的内存。ARC无论理这些类型，只管理Objective-C的对象，因此你仍然须要本身去处理他们。Core Foundation类型可能特别棘手，由于有时他们须要经过桥梁来匹配Objective-C对象，反之亦然。这意味着在Core Foundation类型和Objective-C之间桥接时，须要从ARC来回转移控制。一些和桥接相关的关键字已经被添加了，而且麦克·阿什（Mike Ash）在他漫长的ARC写做中描述了各类桥梁案例。

除此以外，还有其余几个较不频繁但仍然是潜在的问题的案例，在发布的规范中将详细介绍。

基于只要存在一个很强的指针就能够保持对象的不少新的行为，很大程度上与Mac上的垃圾回收很是类似。然而，技术基础是很是不一样的。这种风格的内存管理依赖于咱们在Objective-C中须要遵照的刚性保留/释放规则，而不是有一个按期运行的用来清理再也不被指向的对象的垃圾回收进程。

ARC只须要重复咱们已经作了多年的内存管理任务并将其分流到编译器，因此咱们不再用担忧了。这样，你在垃圾回收平台上就没有中止问题或在经历的锯齿存储器配置问题了。我已经在垃圾回收的Mac应用程序中都经历了这两种，而且很想看到它们在ARC下的行为。

想看更多地关于垃圾回收和ARC，看看Chris Lattner对Objective-C邮件列表的很是有趣的回应，他列出了ARC对Objective-C 2.0垃圾回收的许多优势。我遇到了他所描述的几个垃圾回收问题。

另外

• 简书地址
• 掘金地址