objective-c - existingObjectWithID 死锁与 NSPrivateQueueConcurrencyType

Question

我正在使用 NSPrivateQueueConcurrencyType 并发类型而不是 NSMainQueueConcurrencyType 遇到卡住(死锁？)。

我的上下文初始化:

_managedObjectContext = [[NSManagedObjectContext alloc] 
initWithConcurrencyType:NSPrivateQueueConcurrencyType];  
[_managedObjectContext setPersistentStoreCoordinator:coordinator];

麻烦的代码:

NSManagedObjectID *managedObjectID = [self managedObjectIDForEntity:entity 
withParseObjectId:object.objectId];  
managedObject = [context existingObjectWithID:managedObjectID error:error];

回溯:

Github 链接 project和 open issue对于这个问题的一些背景。

Answer 1

你开枪打中了自己的脸。

executeFetchRequest:error: 创建一个单独的子上下文，它在其中执行一些工作(而父队列被阻塞)。这项工作涉及将工作同步分派(dispatch)到父队列(通过 insertOrUpdateObjects:)。

这是因为带有嵌套上下文的 NSManagedObjectContext -existingObjectWithId: 会分派(dispatch)到父级队列，以实现父级上下文中出错的对象。不幸的是，您已经在子上下文中使用 performBlockAndWait 阻塞了父队列。

随之而来的是巨大的悲伤。

---

编辑:对可能解决方案的思考

这里的问题是由于使用了不同队列的嵌套上下文造成的。我不确定我是否理解在这种情况下使用嵌套上下文的动机，除非提供的上下文是 NSMainQueueConcurrencyType。

即便如此，强制从调用上下文的队列中提取工作也是危险的，因为提取中的任何现有对象如果出现故障(就像这里所做的那样)都会成为这个问题的受害者。

在这种情况下，AFIncrementalStore 可能以某种方式保证图隔离。我发现这个问题针对 AFNetwork 提出:

https://github.com/AFNetworking/AFIncrementalStore/commit/1f822279e6a7096327ae56a2f65ce8e2ff36da83

可疑的相似之处在于，一个保留周期阻止了一个对象被释放，从而导致它永久存在于父上下文中，并试图引发死锁。