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:建立在其上做了一些工作（而父母的隊列阻塞）的單獨子上下文。這項工作涉及到同步分派工作到父母的隊列（通過insertOrUpdateObjects:）。

這是因爲帶有嵌套上下文的NSManagedObjectContext-existingObjectWithId:調度到父節點的隊列以滿足故障進入父上下文的對象。不幸的是，您已經在孩子上下文中阻止了您的父母的排隊performBlockAndWait。

一個巨大的悲傷隨之而來。

---

編輯：上一個可能的解決方案

這裏的問題的思考是通過使用不同的隊列嵌套環境造成的。我不確定我是否理解在這種情況下使用嵌套上下文的動機，除非提供的上下文是NSMainQueueConcurrencyType。

即使這樣，強迫取工作過調用上下文的隊列是危險的，因爲在任何現有對象的獲取會陷入這種問題，如果他們是有故障（如正在這裏進行）。

這是可能的AFIncrementalStore某種程度上保證了在這種情況下，圖中的隔離。我發現這個問題對AFNetwork提起：

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

這是一個保留週期可疑類似被釋放抑制的對象，從而使其永久父背景下存在和死鎖試圖故障。