地址簿线程安全和性能

我从地址簿文档的意义以及对底层CoreData实现的理解表明，地址簿应该是线程安全的，并且使得来自多个线程的查询应该没有问题。但是我很难在文档中找到关于线程安全的明确讨论。这引出了一些问题：地址簿线程安全和性能

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

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

来源

2009-07-16 Rob Napier

地址簿框架目前（并非总是如此）使用核心数据是您应该忽略的实现细节，并不一定能保证线程安全。你能提供一个链接指出地址簿API是线程安全的文档吗？我无法找到文档中描述的线程策略。 – 2009-07-16 14:53:30

我无法找到它。这是我在第一段中提到的观点。我无法在任何文档中找到有关使用AB进行线程化的明确讨论。但假设它不是线程安全的，就会产生很大的复杂性，这是不太需要的（我不能找到关于如何正确实现的文档），因此引发了这个问题。 – 2009-07-16 17:21:48

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

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

这意味着如果sharedManageObjectContext保留NSManagedObjectContext使用，sharedAddressBook将不会是线程安全的。如果AB每次创建一个新的上下文并立即处理它，或者它创建每个线程的上下文并始终使用适当的上下文（可能通过在refDictionary中存储ref）。在任何情况下，将任何东西存储为NSManagedObjects都是不安全的，因为上下文会不断被销毁，这意味着每个ABRecord都必须存储一个NSManagedObjectID，以便在需要时可以在适当的上下文中重新构造该对象。

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

来源

2009-07-17 09:04:05

地址簿线程安全和性能

回答

相关问题