地址簿线程的安全性和性能

Question

我从地址簿文档中了解到我对底层CoreData实现的理解表明，地址簿应该是线程安全的，并且从多个线程进行查询应该没有问题。但是我很难在文档中找到任何关于线程安全的明确讨论。这引出了一些问题：

• 在多个线程上使用+ sharedAddressBook进行只读访问是否安全？我相信答案是肯定的。
• 对于后台线程的写访问权限，您似乎应该使用+ addressBook（并手动保存更改）。我能理解这一点吗？
• 有没有人调查过多个线程上对多个线程进行多个同步查询的性能影响？这应该与在多个线程上进行多个CoreData查询的性能非常相似。我的感觉是，通过进行并行查询我几乎没有收获，因为我认为他们会在遇到SQLLite时进行序列化，但我不确定这里。

我需要针对AddressBook进行几十个查询（一些复杂的），并且我正在使用NSOperation在后台线程上执行此操作，以避免阻止UI（它当前正在执行）。我的基本问题是，将最大并发操作设置为大于1的值是否合理，以及如果应用程序也可能同时在另一个线程上写入AddressBook，是否存在任何危险。

Answer 1

除非API说它是线程安全的，否则它不是。即使当前的实现恰好是线程安全的，也可能不会在未来。换句话说，不要在多个线程中使用AB。

顺便说一句，基于CoreData的内容让你认为它是线程安全的吗？ CoreData使用线程限制模型，只能在单个线程上访问上下文是安全的，必须在同一线程上访问上下文中的所有对象。

这意味着如果sharedManBook保持使用NSManagedObjectContext，那么它将不是线程安全的。只有在每次需要执行某些操作并立即处理它时，或者每个线程创建一个上下文并始终使用适当的上下文（可能通过在threadDictionary中存储ref）时，AB才会创建新的上下文。 。在任何一种情况下，将任何内容存储为NSManagedObjects都是不安全的，因为上下文会不断被破坏，这意味着每个ABRecord都必须存储一个NSManagedObjectID，以便它可以在需要时在适当的上下文中重新构建对象。

显然所有这些都是可能的，它可能是做了什么，但它不是明显的实现。