这个话题已经在很多论坛上讨论过，但我仍然不能完全理解performBlockAndWait 是如何工作的。根据我的理解，context.performBlockAndWait(block: () -> Void) 将在阻塞调用者线程的同时在自己的队列中执行 block 。 Documentation说:

You group “standard” messages to send to the context within a block to pass to one of these methods.

什么是“标准”消息？它还说:

Setter methods on queue-based managed object contexts are thread-safe. You can invoke these methods directly on any thread.

这是否意味着我可以设置在 performBlock* API 中获取的托管对象的属性，而在 performBlock* API 之外的上下文中？

根据我的理解，在并发类型 .MainQueueConcurrencyType 的上下文中调用 performBlockAndWait(block: () -> Void) 将在调用时创建死锁并永远阻塞 UI从主线程。但在我的测试中，它不会造成任何僵局。

我认为它应该创建一个死锁的原因是，performBlockAndWait 将首先阻塞调用者线程，然后在它自己的线程上执行该 block 。由于上下文必须在其中执行其 block 的线程与已经被阻塞的调用者线程相同，因此它永远无法执行其 block 并且该线程将永远处于阻塞状态。

但是，在一些奇怪的情况下，我遇到了僵局。我有以下测试代码:

@IBAction func fetchAllStudentsOfDepartment(sender: AnyObject) {

    let entity = NSEntityDescription.entityForName("Department", inManagedObjectContext: privateContext)
    let request = NSFetchRequest()
    request.entity = entity
    request.relationshipKeyPathsForPrefetching = ["students"]
    var department: Department?

    privateContext.performBlockAndWait { () -> Void in
        department = try! self.privateContext.executeFetchRequest(request).first as? Department
        print(department?.name)
        guard let students = department?.students?.allObjects as? [Student] else {
            return
        }
        for student in students {
            print(student.firstName)
        }
    }
}

@IBAction func fetchDepartment(sender: AnyObject) {

    let entity = NSEntityDescription.entityForName("Department", inManagedObjectContext: privateContext)
    let request = NSFetchRequest()
    request.entity = entity

    privateContext.performBlockAndWait { () -> Void in
        let department = try! self.privateContext.executeFetchRequest(request).first as? Department
        print(department?.name)

    }

    privateContext.performBlockAndWait { () -> Void in
        let department = try! self.privateContext.executeFetchRequest(request).first as? Department
        print(department?.name)
    }
}

请注意，我不小心在测试代码的 fetchDepartment 方法中粘贴了两次 performBlockAndWait。

• 如果我没有调用它不会造成任何死锁 fetchAllStudentsOfDepartment 方法。但是一旦我打电话 fetchAllStudentsOfDepartment，对fetchDepartment 方法的任何调用 永远阻塞 UI。
• 如果我在 fetchAllStudentsOfDepartment 方法中删除 print(student.firstName)，那么它不会阻塞。这意味着，只有当我访问关系的属性时，它才会阻止 UI。

• privateContext 已将 concurrencyType 设置为 .PrivateQueueConcurrencyType。仅当 privateContext 的 parentContext 将 concurrencyType 设置为 .MainQueueConcurrencyType 时，以上代码才会阻塞 UI。

  我也用其他 .xcdatamodel 测试了相同的代码，现在我确信它只会在访问关系的属性时阻塞。我当前的 .xcdatamodel 看起来像:

如果信息无关，请原谅我，但我只是在花了大约 8 个小时后分享我的所有观察结果。当 UI 被阻塞时，我可以发布我的线程堆栈。总而言之，我有三个问题:

1. 什么是“标准”消息？
2. 我们能否设置在 performBlock* API 中获取的托管对象的属性，以及在 performBlock* 之外的上下文的 API？
3. 为什么 performBlockAndWait 在我的测试代码中行为不当并导致 UI 阻塞。

测试代码:您可以从here 下载测试代码。 .

最佳答案

1. 标准消息是古老的 Objective-C 行话。这意味着您应该在 performBlock 或 performBlockAndWait 中对 ManagedObjectContext 及其子 ManagedObjects 执行所有常规方法调用。在 block 外的私有(private)上下文中唯一允许的调用是 init 和 setParentContext。其他任何事情都应该在一个 block 中完成。

2. 没有。从私有(private)上下文中获取的任何托管对象只能在该私有(private)上下文的队列中访问。从另一个队列访问(读取或写入)违反了线程限制规则。

3. 您遇到阻塞问题的原因是您有两个级别的“mainQueue”上下文，这“智取”了队列系统。这是流程:

   • 您在主队列上创建一个上下文，然后将其创建为另一个主队列上下文的子级。
   • 您创建该第二层主队列上下文的私有(private)子级
   • 您访问该私有(private)队列上下文的方式使其试图在当前已加载到主队列上下文中的对象中出错。

由于主队列上下文的两个级别，它会导致死锁，而队列系统通常会发现潜在的死锁并避免它。

您可以通过将 mainContext 变量更改为:

lazy var mainContext: NSManagedObjectContext = {
    let appDelegate = UIApplication.sharedApplication().delegate as? AppDelegate
    return appDelegate!.managedObjectContext
}

并且您的问题消失了，因为队列系统会看到该 block 并避免它。您甚至可以通过在 performBlockAndWait() 中放置一个断点来看到这种情况的发生，并看到您仍在主队列中。

最后，没有理由像在父/子设计中那样拥有两级主队列上下文。如果有的话，这是不这样做的一个很好的论据。

更新

我错过了您更改了 appDelegate 中的模板代码并将整个上下文变成私有(private)上下文。

每个 vc 都有一个主 MOC 的模式抛弃了 Core Data 的很多好处。虽然在顶部有一个 private 和一个主 MOC(它存在于整个应用程序，而不仅仅是一个 VC)是一个有效的设计，但如果你从主排队。

我不建议在主队列中使用 performBlockAndWait，因为您会阻塞整个应用程序。 performBlockAndWait 只应在调用 TO 主队列(或一个背景到另一个背景)时使用。

关于ios - 访问关系时核心数据privateQueue performBlockAndWait死锁，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34563690/