除非在后台线程中获取新的引用，否则存在潜在的引用计数问题

我有一个second https://stackoverflow.com/questions/28898966/prefer-property-accessor-or-kvc-style-for-accessing-core-data-properties阅读 Marcus S. Zarra 的文章后提出的问题（优秀）核心数据：iOS、OS X 和 iCloud 的数据存储和管理 https://pragprog.com/book/mzcd2/core-data（第二版）如果可以的话。

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

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并可能导致 不必要的引用计数问题。

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

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

这就是全部内容吗？还是有更微妙的情况也构成引用计数问题，并且可能在这种情况下实现？

就目前情况而言，我不会（显着）担心这种特殊情况下潜在的引用计数问题（调度立即执行的简单后台操作），但也许我遗漏了一些东西。

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

通过调用管理器来检索协调器的新引用，您首先确保您将获得最新的协调器，并且保持当前协调器不保留在块中。如果您要从块外部重用协调器，则该协调器将被保留，并可能会产生（尽管不太可能）问题，例如内存膨胀。如果一切都变坏并且该块甚至从未被执行，那么协调器将被永远保留，并且您会出现内存泄漏。

这只是一个很好的做法。