0

我想我有一个问题，可能与核心数据中的保留周期有关。代码如下，其中 self.image 也是一个 NSManagedObject：

- (void)setImage:(UIImage*)image1 andThumbnail:(UIImage*)image2
{
    self.image.data = UIImageJPEGRepresentation(image1, 0.85); // This is autoreleased
    self.thumbnail = UIImageJPEGRepresentation(image2, 0.85); // This is autoreleased
}

显然，“self.image.date =”有一个永远不会释放的保留（我认为它在 self.image 和 self 之间）。因此，self 对象将永远不会被释放，因此会泄漏。

编辑：所以基本上我和这里有同样的问题：https ://devforums.apple.com/message/246219#246219 我使用完全相同的结构，其中前面代码中的 self 对应于给定链接中的 Bar 。我也有相同的视图控制器结构。但是， refreshObject 没有帮助。

我尝试使用 NSManagedObjectContext refreshObject 方法来打破保留周期（如 Apple 文档中所建议的那样）。它对retainCount 没有影响。我可能没有以正确的方式使用它，但我找不到太多关于它的信息。如果我使用 NSManagedObjectContext:reset: 当我回到根视图控制器时会崩溃。

谢谢！

4

1 回答 1

2

您不应干扰托管对象上下文对托管对象内存的管理。

如果self.image上面是一个托管对象并且您没有编写自定义访问器，那么您就没有内存管理问题。任何手动管理上下文内存的尝试几乎总是会导致比解决的问题更多的问题。

除了在最简单和最小的命令行应用程序中，保留计数不会告诉您任何信息。一旦你使用像 Core Data 这样的框架，幕后的保留非常复杂，以至于保留计数通常与你自己的代码中发生的事情无关。

显然，“self.image.date =”有一个永远不会释放的保留（我认为它在 self.image 和 self 之间）。因此，self 对象将永远不会被释放，因此会泄漏。

这不会发生。在终止实例本身之前，您不必终止实例保留属性中的所有对象。如果这是真的，你就不能杀死一个与第三个对象共享属性对象的实例。如果它们是非 managedObject 实例，则该self.image对象可以在对象死后很长时间仍然存在self。只有上下文对实体图的强制执行使它们的行为有所不同，这与内存管理无关。

如果您在托管对象上看到一个神秘的保留计数 1，那就是托管对象上下文对对象的保留。只要上下文认为托管对象必须存在于实体图中，它就永远不会释放该对象。

如果泄漏完全在核心数据堆栈中，那么您的问题很可能出在self实体和实体之间的实体图中self.image。实体图正在防止其中一个或另一个被拒绝或必需的关系最有可能被删除。

于 2010-06-26T16:43:09.143 回答