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

概述我从地址簿文档中了解到我对底层CoreData实现的理解表明,地址簿应该是线程安全的,并且从多个线程进行查询应该没有问题.但是我很难在文档中找到任何关于线程安全性的明确讨论.这引出了一些问题： >在多个线程上使用sharedAddressBook进行只读访问是否安全？我相信答案是肯定的. >对于后台线程的写访问权限,您似乎应该使用addressBook(并手动保存更改).我能正确理解吗？ >是否有 我从地址簿文档中了解到我对底层CoreData实现的理解表明,地址簿应该是线程安全的,并且从多个线程进行查询应该没有问题.但是我很难在文档中找到任何关于线程安全性的明确讨论.这引出了一些问题：

>在多个线程上使用sharedAddressBook进行只读访问是否安全？我相信答案是肯定的.
>对于后台线程的写访问权限,您似乎应该使用addressBook(并手动保存更改).我能正确理解吗？
>是否有人调查过在多个线程上对通讯簿进行多个同时查询的性能影响？这应该与在多个线程上进行多个CoreData查询的性能非常相似.我的感觉是,通过进行并行查询我几乎没有收获,因为我认为他们会在命中sqllite时进行序列化,但我不确定这里.

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

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

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

这意味着如果sharedAddressBook保持NSManagedobjectContext使用,那么它将不是线程安全的.如果AB每次需要做某事并立即处理它时创建一个新的上下文,或者它为每个线程创建一个上下文并且总是使用适当的上下文(可能通过在threadDictionary中存储ref),那将是安全的. .在任何一种情况下,将任何内容存储为NSManagedobjects都是不安全的,因为上下文会不断被破坏,这意味着每个ABRecord都必须存储NSManagedobjectID,以便它可以在需要时在适当的上下文中重新构建对象.

显然所有这一切都是可能的,它可能是做了什么,但它不是明显的实施.

总结

以上是内存溢出为你收集整理的cocoa – 地址簿线程的安全性和性能全部内容，希望文章能够帮你解决cocoa – 地址簿线程的安全性和性能所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。