Ios CoreData、MagicalRecord和长寿命ManagedObjectContext

我们有一个iOS应用程序，它使用MagicalRecord处理CoreData。我一直在努力释放我们的主线程，并将更多的处理放在后台线程上。我们一直在使用MR_contextForCurrentThread方法，该方法已被弃用，我的第一次尝试是通过saveWithBlock将其替换为短期工作上下文，正如本文所建议的：

但是，我遇到了一个问题，即在多个短期后台工作上下文中同时创建/删除/更新相同的托管对象，这导致了保存时的并发性问题。我通过创建一个后台工作上下文来解决这个问题，该上下文存储在一个静态变量中，类似于MagicalRecord defaultContext和rootContext的存储方式，并使用performBlock对这个工作上下文执行所有操作

这成功地解决了save并发性问题，但我想知道这样使用长期的后台工作上下文是否真的是一种可靠的方法。在上面提到的博文中，索尔·莫拉写道：

假设您有一个通过contextForCurrentThread方法创建的上下文，然后保留对该上下文的引用。然后将更多块提交到队列中，并使用相同的上下文。最终可能会有一个或多个新提交的块在创建上下文的线程之外的线程上运行。而且，虽然这本身并不意味着你的应用程序突然死亡，但最终会发生崩溃，因为上下文访问错误的线程，即使队列是相同的。”

我想知道，如果上述情况属实，为什么它不影响MagicalRecord中使用的静态rootContext对象（这是一个私有队列上下文）它不会受到GCD队列/线程交换的影响，但我认为rootContext会受到影响，因为保存块总是针对其私有队列执行

如果一个长期存在的上下文即使总是使用performBlock来处理，也确实不安全，那么对于处理可能同时在同一托管对象上运行的后台操作，建议采用什么策略