对象的所有权和销毁

对一个程序来说，最好是尽可能少地使用内存。因此，Objective-C环境中定义了一些机制和策略，允许您对程序的内存进行管理。虽然您可以从底层实现的角度去考虑Objective-C程序的内存管理（详见“幕后：保留计数”），但是通常从对象所有权的角度来考虑这个问题会更容易。

在 Objective-C 程序中，对象会被创建和销毁。为了确保您的应用程序不会使用不必要的内存，对象应该在不需要它们的时候被销毁。当然，在需要对象时保证它们不被销毁也很重要。为了满足这些需求，Cocoa定义了一种机制—对象所有权，通过该机制您可以指定您何时需要使用一个对象，又在何时完成对该对象的使用。

为了充分理解对象所有权策略在Cocoa中是如何实现的，您还需要阅读“自动释放池”这部分的内容。

任何对象都可能拥有一个或多个所有者。只要一个对象至少还拥有一个所有者，它就会继续存在。如果一个对象没有所有者，则运行时系统会自动销毁它（参考“回收对象”）。为了确保您清楚自己何时拥有一个对象而何时不拥有对象，Cocoa设置了以下策略：

任何您自己创建的对象都归您所有。

您可以使用名字以“alloc”或“new”开头或名字中包含“copy”的方法（例如alloc，newObject，或mutableCopy）来“创建”一个对象。

您可以使用retain来获得一个对象的所有权。

请记住，一个对象的所有者可能不止一个。拥有一个对象的所有权就表示您需要保持该对象存在。（“存取方法”更详细地讨论了这部分内容。）

当您不再使用您所拥有的对象时，您必须释放对这些对象的所有权。

您可以通过向一个对象发送release消息或autorelease消息（在“自动释放”这一部分更详细地讨论了autorelease）来释放您对它的所有权。因此，用Cocoa的术语来说，释放对象的所有权通常被称为“释放”（releasing）对象。

您不能释放非您所有的对象的所有权。

这主要是前面的策略规则的一个隐含的推论，在这里将其明确地提出。

这条策略对基于GUI的Cocoa应用程序和命令行Foundation工具都适用。

请仔细思考下面的代码片段：

{

这个例子完全遵守上述策略。您使用alloc方法创建了Thingamajig对象，因此，随后您在不需要该对象时对其发送了一条release消息。当您通过Thingamajig对象获得sprockets数组时，您并没有“创建”这个数组，所以您也没有对其发送release消息。

所有权策略是在调用retain方法后通过引用计数—通常被称为“保留计数”—实现的。每个对象都有一个保留计数。

当您创建一个对象时，该对象的保留计数为1。

当您向一个对象发送retain消息时，该对象的保留计数加1。

release消息时，该对象的保留计数减1。

当您向一个对象发送autorelease消息时，该对象的保留计数会在将来的某个阶段减1。

如果一个对象的保留计数被减为0，该对象就会被回收（请参考“回收对象”）。

重要：通常您不必显式地查询对象的保留计数是多少（参考retainCount）。其结果往往容易对人产生误导，因为您可能不知道您感兴趣的对象由何种框架对象保留。在调试内存管理的问题上，您只需要确保您的代码遵守所有权规则。

NSObject对象定义的autorelease方法为后续的释放标记了接收者。通过向对象发送autorelease消息，您亦是声明：在您发送消息的作用域之外，您不想再保留该对象。这个作用域的范围是由当前的自动释放池定义的，可参考“自动释放池”。

您可以这样实现上面提到的sprockets方法：

当另一个方法得到Sprocket对象的数组时，这个方法可以假设：当不在需要该数组时，它会被销毁，但仍可以在其作用域内的任何地方被安全地使用（请参考“共享对象的有效性”）。该方法甚至可以将数组返回给它的调用者，因为应用程序对象为您的代码定义好了调用堆栈的底部。

autorelease方法可以使您很轻松地从一个方法返回一个对象，并且仍然遵循所有权策略。为了说明这一点，来看两个sprockets方法的错误实现：

这种做法是错误的。根据所有权策略，这将会导致内存泄漏。

对象只能在sprockets方法的内部引用新的数组对象。在该方法返回后，对象将失去对新对象的引用，导致其无法释放所有权。这本身是没有问题的。但是，按照先前提出的命名约定，调用者并没有得到任何提示，不知道它已经获得了返回的对象。因此调用者将不会释放返回的对象的所有权，最终导致内存泄漏。

这种做法也是错误的。虽然对象正确地释放了新数组的所有权，但是在release消息发送之后，新数组将不再具有所有者，所以它会被系统立即销毁。因此，该方法返回了一个无效（已释放）的对象：

最后，您还可以像这样正确地实现 NSArray *array = [NSArray arrayWithObjects:mainsprocket,102); margin-right:0.333em; margin-left:0.5em; line-height:13px; white-space:pre-wrap"> return array; 您并没有拥有arrayWithObjects:返回的数组，因此您不用负责释放所有权。不过，您可以通过sprockets方法安全地返回该数组。

initWithContentsOfFile:encoding:error: (Nsstring)

executeFetchRequest:error: (NSManagedobjectContext)

在这些情况下，前面描述的规则同样适用。当您调用这些方法中的任何一种时，由于您没有创建NSError对象，因此您不会拥有该对象—同样也无需释放它。

如果因为任何原因，返回的对象的所有权不能遵守基本规则，这将在方法的文档中明确地阐明（例如，参考dataFromPropertyList:format:errorDescription:）。

在某些情况下，两个对象之间可能会出现循环引用的情况，也就是说，每一个对象都包含一个实例变量引用对方对象。例如，考虑一个文本程序，程序中对象间的关系如图1所示。“文档（document）”对象为文档中的每个页面创建一个“页（Page）”对象。每个Page对象具有一个实例变量，用来跟踪该页所在的文档。如果document对象保留了Page对象， 同时Page对象也保留document对象，则这两个对象都永远不会被释放。只有Page对象被释放，document的引用计数才能变为0，而只有document对象被回收，Page对象才能被释放。

图 1  保留循环示意图

针对保留循环问题的解决方案是“父”对象应保留其“子”对象，但子对象不应该保留其父对象。因此，在图1中，document对象要保留page对象，但page对象不保留document对象。子对象对其父对象的引用是一个弱引用的例子，这部分内容在“对象的弱引用”有更充分的描述。

保留一个对象创建了一个对该对象的“强”引用。一个对象只有在它的所有强引用都被释放后才能被回收。因此，一个对象的生命周期取决于其强引用的所有者。在某些情况下，这种行为可能并不理想。您可能想要引用一个对象而不妨碍对象本身的回收。对于这种情况，您可以获取一个“弱”引用。弱引用是通过存储一个指向对象的指针创建的，而不是保留对象。

弱引用在可能会出现循环引用的情况下是必不可少的。例如，如果对象A和对象B互相通信，两者都需要引用对方。如果每个对象都保留对方对象，则这两个对象只有在它们之间的连接中断后才能被回收，但是它们之间的连接又只能在有对象被回收后才能中断。为了打破这种循环，其中一个对象需要扮演从属角色，得到另一个对象的一个弱引用。举个具体的例子，在视图层次中，父视图拥有其子视图，也因此能够保留子视图，但父视图并不归子视图所有；然而子视图仍需要知道谁是它的父视图，因此它保持一个对其父视图的弱引用。

Cocoa中弱引用的其他适用情况包括：表格数据源，大纲视图项，通知观察者以及其余项目标和委托，但不仅限于上述情况。

在向您弱引用的对象发送消息时，您需要小心谨慎。如果您在一个对象被回收之后向它发送消息，您的应用程序将会崩溃。您必须为对象何时有效制定有明确界定的条件。在大多数情况下，被弱引用的对象知道其他对象对它的弱引用，这和循环引用的情况是一样的，并且它还能够在自己被回收时通知其他对象。例如，当您向通知中心注册一个对象的时候，通知中心会存储一个对该对象的弱引用，并且在适当的消息发布时，还会向该对象发送消息。当对象被回收时，您需要向通知中心解注册该对象，以防通知中心向这个已经不存在的对象继续发送消息。同样，当一个委托对象被回收时，您需要通过向其他对象发送一条带nil参数的setDelegate:消息来删除委托链接。这些消息通常由对象的dealloc方法发出。

通常，不应该由您来管理一些稀缺资源，比如文件描述符，网络连接和dealloc方法中的缓冲区/高速缓存。特别地，您设计的类不应该让您错误地认为dealloc会在您觉得该调用的时候被调用。dealloc的调用可能会因为bug或应用程序销毁而被延误或回避。

相反，如果您有一个类，由它的实例管理稀缺资源，则您在设计应用程序时应该让自己知道何时不再需要这些资源，并且可以在那个时刻通知实例“清理”这些资源。通常，接下来您应该释放该实例，然后调用dealloc，但如果您不这样做也不会有问题。

如果您试图让dealloc肩负起资源管理的责任，会出现的一些问题：

对象图销毁的顺序依赖性。

对象图销毁机制内在是无序的。虽然通常您可能期望甚至得到一个特定的顺序，但是这样做的同时您也引入了脆弱性。如果一个对象意外落入自动释放池，则销毁顺序会改变，这可能会导致意想不到的后果。

稀缺资源的未回收。

内存泄露当然是应该被修复的BUG，但它们一般来说不会是直接致命的错误。然而，如果稀缺资源在您希望它们被释放时没有被释放，这会导致非常非常严重的问题。例如，如果您的应用程序耗尽了文件描述符，那么用户可能无法保存数据。

清除在错误的线程上被执行的逻辑。

如果一个对象在意外的时刻落入自动释放池，那么无论它进入哪个线程池，它都将被回收。这对于那些本应该只由一个线程访问的资源来说很容易产生致命的错误。

转自：http://www.apple.com.cn/developer/iphone/library/documentation/UserExperIEnce/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.HTML

以上是内存溢出为你收集整理的对象的所有权和销毁全部内容，希望文章能够帮你解决对象的所有权和销毁所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。