地址簿線程安全和性能

Question

我從地址簿文檔的意義以及對底層CoreData實現的理解表明，地址簿應該是線程安全的，並且使得來自多個線程的查詢應該沒有問題。但是我很難在文檔中找到關於線程安全的明確討論。這引出了一些問題：

• 在多線程上使用+ sharedAddressBook以安全地訪問只讀嗎？我相信答案是肯定的。
• 對於後臺線程的寫入訪問，您應該改爲使用+ addressBook（並手動保存更改）。我是否理解正確？
• 有沒有人調查過對多個線程進行多個同時查詢到地址簿的性能影響？這應該與在多個線程上進行多個CoreData查詢的性能非常相似。我的感覺是，通過進行並行查詢，我可以獲得很少的收益，因爲我們假設他們在碰到SQLLite時會序列化，但我不確定。

我需要對AddressBook進行幾十個查詢（一些複雜的），並且在後臺線程上使用NSOperation來避免阻塞UI（它目前所做的）。我的根本問題是，將最大併發操作設置爲大於1的值是否有意義，以及如果應用程序也可能在另一個線程上同時寫入AddressBook，是否存在任何危險。

Answer 1

除非API說它是線程安全的，否則不是。即使當前的實現碰巧是線程安全的，它可能不會在未來。換句話說，不要在多個線程中使用AB。

順便說一句，它是基於CoreData的是什麼讓你認爲它會是線程安全的？ CoreData使用線程約束模型，只有在單個線程上訪問上下文才是安全的，上下文中的所有對象都必須在同一個線程上訪問。

這意味着如果sharedManageObjectContext保留NSManagedObjectContext使用，sharedAddressBook將不會是線程安全的。如果AB每次創建一個新的上下文並立即處理它，或者它創建每個線程的上下文並始終使用適當的上下文（可能通過在refDictionary中存儲ref） 。在任何情況下，將任何東西存儲爲NSManagedObjects都是不安全的，因爲上下文會不斷被銷燬，這意味着每個ABRecord都必須存儲一個NSManagedObjectID，以便在需要時可以在適當的上下文中重新構造該對象。

顯然，所有這些都是可能的，可能是做了什麼，但它不是明顯的實現。