我们有一个iOS应用程序，它使用MagicalRecord进行CoreData。我一直在努力释放我们的主线程并将更多的处理放到后台线程上。我们一直在使用MR_contextForCurrentThread方法，该方法已被弃用，我的第一次尝试是通过saveWithBlock将其替换为短期工作者上下文，如本博客文章中所述：
然而，我遇到了一个问题，即在同一时间在多个短期后台工作者上下文中创建/删除/更新相同的托管对象，这导致了保存时的并发问题。我通过创建一个后台工作者上下文来解决这个问题，该上下文存储在类似于MagicalRecord defaultContext和rootContext的存储方式的静态变量中，并使用performBlock对这一个工作者上下文执行所有操作。这成功解决了保存并发问题，但我想知道使用像这样的长期后台工作者上下文是否真的是一个可靠的方法。在上面引用的博客文章中，Saul Mora写道：
“假设你有一个通过contextForCurrentThread方法创建的上下文，然后保持对该上下文的引用。然后你将更多的块提交到队列，并使用相同的上下文。最终可能有一个或多个新提交的块将在不是创建上下文的线程的线程上运行。而且，虽然这并不意味着您的应用程序突然死亡，但最终会出现崩溃，因为上下文是访问的错误的线程，即使队列是相同的。“
我想知道，如果上述情况确实如此，为什么它不会影响MagicalRecord中使用的静态rootContext对象（私有队列上下文）。 defaultContext（主队列上下文）不会受到此GCD队列/线程交换潜力的影响，但我认为rootContext将是，因为特别是保存块一直针对其私有队列执行。
如果长期上下文确实不安全，即使总是使用performBlock处理它，那么处理可能同时在同一个托管对象上运行的后台操作的推荐策略是什么？