核心数据保存竞争条件错误

Question

我有一个NSOperation，它会更新应用数据。此操作有自己的上下文，更改通过contextDidSave 通知传递回主线程上的上下文。

更新操作删除对象。这些删除会无意中导致崩溃。当主线程在保存更新上下文的同时重新加载UITableView 时会发生崩溃。 tableview 的数据源由NSFetchedResultsController 支持。

CoreData 或 UIKit 都不输出任何日志记录。崩溃是在访问 managedObject 的属性时在tableView:cellForRowAtIndexPath: 中发生的 SIG_ABRT。这是成功更新的结果。您可以看到表格被填充一次，然后上下文保存，这反过来又导致表格被重新加载：

tableView:numberOfRowsInSection: rowCount = 29
tableView:cellForRowAtIndexPath: row: 0
tableView:cellForRowAtIndexPath: row: 1
tableView:cellForRowAtIndexPath: row: 2
tableView:cellForRowAtIndexPath: row: 3
tableView:cellForRowAtIndexPath: row: 4
tableView:cellForRowAtIndexPath: row: 5
tableView:cellForRowAtIndexPath: row: 6
tableView:cellForRowAtIndexPath: row: 7
tableView:cellForRowAtIndexPath: row: 8
tableView:cellForRowAtIndexPath: row: 9
Will saved update context
Did saved update context
Will merge update context
tableView:numberOfRowsInSection: rowCount = 58
Did merge update context
tableView:numberOfRowsInSection: rowCount = 29
tableView:cellForRowAtIndexPath: row: 0
tableView:cellForRowAtIndexPath: row: 1
tableView:cellForRowAtIndexPath: row: 2
tableView:cellForRowAtIndexPath: row: 3
tableView:cellForRowAtIndexPath: row: 4
tableView:cellForRowAtIndexPath: row: 5
tableView:cellForRowAtIndexPath: row: 6
tableView:cellForRowAtIndexPath: row: 7
tableView:cellForRowAtIndexPath: row: 8
tableView:cellForRowAtIndexPath: row: 9

这是发生崩溃时的输出：

tableView:numberOfRowsInSection: rowCount = 29
tableView:cellForRowAtIndexPath: row: 0
tableView:cellForRowAtIndexPath: row: 1
tableView:cellForRowAtIndexPath: row: 2
Will saved update context
tableView:cellForRowAtIndexPath: row: 3
tableView:cellForRowAtIndexPath: row: 4
tableView:cellForRowAtIndexPath: row: 5

我能想到两种可能的解决方案：

1. 在刷新表视图时锁定persitentStoreCoordinator。 （这可以通过继承 UITableView 并覆盖 reloadData 来提供锁定和解锁商店的位置）
2. 将删除推迟到以后的日期，例如，当应用程序退出时。 （这可以通过向实体添加 isStale 属性或通过创建新的 Trash 实体并向其添加对象来完成。）

但是，这两种解决方案看起来都非常老套。我错过了什么吗？我的第一个想法是尝试让NSFetchedResultsController 预取所有对象，但这是不可能的。另一种可能的解决方案是在使用controllerDidChangeContent: 时锁定存储，但是当 fetchedResultsController 未触发表重新加载时问题仍然存在。

Answer 1

正如其他人所提到的，堆栈跟踪至关重要。没有我们只能猜测解决方案。