cocoa - 地址簿线程安全和性能

Question

我从地址簿文档中得到的感觉以及我对底层 CoreData 实现的理解表明地址簿应该是线程安全的，并且从多个线程进行查询应该不会造成任何问题。但我在文档中找不到任何关于线程安全的明确讨论。这提出了几个问题:

• 在多个线程上使用 +sharedAddressBook 进行只读访问是否安全？我相信答案是肯定的。
• 对于后台线程上的写入访问，您似乎应该使用+addressBook(并手动保存更改)。我的理解正确吗？
• 有人调查过在多个线程上同时对地址簿进行多个查询对性能的影响吗？这应该与在多个线程上进行多个 CoreData 查询的性能非常相似。我的感觉是，通过并行查询我不会获得什么好处，因为我假设它们在访问 SQLLite 时会序列化，但我在这里不确定。

我需要对 AddressBook 进行数十个查询(有些复杂)，并且正在使用 NSOperation 在后台线程上执行此操作，以避免阻塞 UI(目前确实如此)。我的根本问题是将最大并发操作设置为大于 1 的值是否有意义，以及如果应用程序可能同时在另一个线程上写入 AddressBook，这样做是否有任何危险。

Answer 1

除非 API 声明它是线程安全的，否则它就不是。即使当前的实现恰好是线程安全的，但将来也可能不再安全。换句话说，不要从多个线程使用 AB。

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

这意味着如果sharedAddressBook保留一个NSManagedObjectContext来使用，它就不是线程安全的。只有AB每次需要做某事时创建一个新的上下文并立即处理它，或者如果它为每个线程创建一个上下文并始终使用适当的上下文(可能通过在threadDictionary中存储对其的引用)，这才是安全的。在任何一种情况下，将任何内容存储为 NSManagedObjects 都是不安全的，因为上下文会不断被破坏，这意味着每个 ABRecord 都必须存储一个 NSManagedObjectID，以便它可以在需要时在适当的上下文中重新构造对象。

显然，所有这些都是可能的，这可能就是所做的事情，但这并不是明显的实现。