Core Data 的多线程使用（NSOperationQueue 和 NSManagedObjectContext）答案

【问题标题】：Multithreaded use of Core Data (NSOperationQueue and NSManagedObjectContext)Core Data 的多线程使用（NSOperationQueue 和 NSManagedObjectContext）
【发布时间】：2010-11-30 01:57:00
【问题描述】：

在 Apple 的 Concurrency with Core Data 核心数据文档中，他们列出了线程安全的首选方法，即每个线程使用单独的 NSManagedObjectContext，并使用共享的 NSPersistentStoreCoordinator。

如果我在一个 NSOperationQueue 上一个接一个地运行多个 NSOperation，是否会为每个任务创建上下文的开销很大？

由于 NSOperationQueue 的最大并发操作数为 1，我的许多操作将使用同一个线程。我可以使用线程字典为每个线程创建一个 NSManagedObjectContext 吗？如果这样做，以后清理上下文会不会有问题？

在这种情况下使用 Core Data 的正确方法是什么？

【问题讨论】：

标签： iphone objective-c multithreading core-data

【解决方案1】：

使用 NSOperationQueue 启动的最大并发操作计数为 1 的操作不会在同一线程上运行所有操作。操作会一个接一个地执行，但每次都会创建一个新线程。

所以在线程字典中创建对象用处不大。

【讨论】：

无法保证每次都是新线程。事实上，在 Snow Leopard 上，NSOperationQueue 使用显式重用线程的 Grand Central Dispatch。
这个问题是关于 iPhone 的，不是关于雪豹的。当然也没有保证，有吗？

【解决方案2】：

在这种情况下使用 Core Data 的正确方法是为每个操作创建一个单独的NSManagedObjectContext或以拥有一个您锁定的上下文（使用前通过-[NSManagedObjectContext lock] 和-[NSManagedObjectContext unlock]使用后）。如果操作是串行的并且没有其他线程使用上下文，则锁定方法可能有意义。

使用哪种方法是一个经验性问题，没有数据就无法回答。变量太多，无法形成一般规则。性能测试中的硬性数据是做出明智决定的唯一方法。

【讨论】：

仅供参考 - lock 和 unlock 在 iOS8 和 OSX 10.10 中已弃用。建议是：“使用队列样式上下文和 -performBlockAndWait: 代替”

【解决方案3】：

虽然这个问题很老，但它实际上在 Google 的“NSMangedObjectContext threading”搜索结果的顶部，所以，我将只提供一个新答案。

新的“首选”方法是使用 initWithConcurrencyType: 并告诉 MOC 它是主线程 MOC 还是辅助线程 MOC。然后，您可以在其上使用新的 performBlock: 和 performBlockAndWait: 方法，MOC 将负责在其“本机”线程上进行序列化操作。

然后问题就变成了如何智能地处理合并应用程序可能产生的各种 MOC 之间的数据，以及让程序员的生活变得“有趣”的一千个其他细节。

【讨论】：