潜在的引用计数问题，除非在后台线程中获取新引用 [英] Potential reference count issues unless grabbing fresh reference in background thread

问题描述

我有秒问题，阅读Marcus S. Zarra的（优秀） 核心数据：iOS数据存储和管理，OS X和iCloud （第2版）。

I have a second question after reading Marcus S. Zarra's (excellent) Core Data: Data Storage and Management for iOS, OS X, and iCloud (2nd edition) if I may.

书的部分异步添加NSPersistentStore 包含这段代码（摘录）：

The book's section Asynchronously Adding the NSPersistentStore contains this piece of code (excerpt):

dispatch_queue_t queue;
queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{

    // ...

    NSPersistentStoreCoordinator *coordinator = nil;
    coordinator = [[self managedObjectContext] persistentStoreCoordinator];

    // ...
});

它还包含此解释：

我们获取对
NSPersistentStoreCoordinator 的新引用的原因是安全性。如果我们使用外部方法中的
引用，我们将递增 NSPersistentStoreCoordinator 的retain
计数，并可能导致
不必要的引用计数问题。

The reason we grab a fresh reference to the NSPersistentStoreCoordinator is one of safety. If we were to use the reference from the outer method, we would be incrementing the retain count of the NSPersistentStoreCoordinator and potentially causing an unnecessary reference count issue.

这个潜在引用计数问题的性质是什么？

What is the nature of this potential reference count issue?

我理解，如果调度块引用外部范围的 NSPersistentStoreCoordinator ，它将保留该协调器（将引用计数增加一）那么只有在块完成执行之后才能被释放。如果后台线程从未执行过或者它不会终止，引用计数问题仍然存在。

I understand that if the dispatched block would refer to a NSPersistentStoreCoordinator that is scoped outside, it would retain that coordinator (increase its reference count by one), which then could be released only after the blocks has finished execution. If the background thread never executed or if it would not terminate, a reference count issue would remain.

这是所有的事情还是有更多微妙的情况，也将构成引用计数问题，并可能在这种情况下实现？

Is that all there is to it or are there more subtle cases that would also constitute reference count issues and that could materialize in this situation?

由于这种情况，我不会（显着地）关注在这种特殊情况下的潜在引用计数问题（简单的后台操作被分派为立即执行），但也许我失去了一些东西。 p>

As it stands, I would not be (significantly) concerned about a potential reference count issue in this particular case (simple background operation that is dispatched for immediate execution) but maybe I am missing something.

推荐答案

在这个例子中，块本身可以执行相对较晚（很多其他代码可以在这个块之前执行）。这意味着上下文或商店协调器可能发生很多事情，假设商店协调器在块开始执行之前和之后都不是同一个对象。

The block itself could be executed relatively late in this example (a lot of other code could execute before this block). Which means much can happen to the context or the store coordinator and hypothetically the store coordinator is not even the same object before and after the block starts executing.

通过调用管理器要检索协调器的新引用，您首先确保您将获得最新的协调器，以及保持当前协调器不被阻止。如果你要从块外部重用协调器，协调器将被保留，并且可能产生（虽然不太可能）问题，例如内存膨胀。如果一切都坏了，并且块从未被执行，则协调器将永远保留，并且您有内存泄漏。

By calling the manager to retrieve the new reference for the coordinator you ensure first that you will get the latest coordinator as well as you keep the current coordinator unretained from the block. If you were to reuse the coordinator from outside the block that coordinator will be retained and may produce (although unlikely) issues such as memory inflating. And if all goes bad and the block is never even executed the coordinator is simply retained forever and you have a memory leak.

这只是一个好的做法。

This is just a good practice.

这篇关于潜在的引用计数问题，除非在后台线程中获取新引用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！