Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/ios/122.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Ios 2种不同的NSManagedObjectContexts保存导致无限内存分配_Ios_Core Data - Fatal编程技术网

Ios 2种不同的NSManagedObjectContexts保存导致无限内存分配

Ios 2种不同的NSManagedObjectContexts保存导致无限内存分配,ios,core-data,Ios,Core Data,我遇到了一个奇怪的问题。我有以下设置: Model.xcdatamodeld ModelBackup.xcdatamodeld 每一个都有自己的NSManagedObjectContextNSPersistantStoreCoordinator和NSManagedObjectModel 我可以分别成功地读写这些文件。但是,如果我在读取/写入ModelBackup的同时尝试读取/写入Model,我会得到无限的内存分配。在模拟器中,CPU将达到200%,内存将增加约80-100 MB/秒。当内存达到

我遇到了一个奇怪的问题。我有以下设置:

Model.xcdatamodeld

ModelBackup.xcdatamodeld

每一个都有自己的
NSManagedObjectContext
NSPersistantStoreCoordinator
NSManagedObjectModel

我可以分别成功地读写这些文件。但是,如果我在读取/写入
ModelBackup
的同时尝试读取/写入
Model
,我会得到无限的内存分配。在模拟器中,CPU将达到200%,内存将增加约80-100 MB/秒。当内存达到2.0+GB时,这将最终崩溃。当我对这两个
NSManagedObjectContext
s执行
上下文保存时,就会发生这种情况。我可以很好地阅读/访问它们

有人知道我为什么不能给这两个都写信吗

我有
Model
ConcurrencyType:NSMainQueueConcurrencyType
以及
ModelBackup
ConcurrencyType:NSPrivateQueueConcurrencyType


拥有两个不同的
xcdatamodeld
背后的想法是一种解决方案/替代方案,即
父子
核心数据模式。我们的应用程序正在对
数据模型进行大量更新,因此我想让后台数据模型执行这些更新,然后当应用程序下次启动时,切换到新更新的sqlite。

首先,您可以对父/子数据模型进行大量更新,只要您注意每次保存时写入磁盘的量

其次,可以将两个
NSPersistentStoreCoordinator
实例指向同一个sqlite文件,并避免使用两个文件

第三,创建这些上下文时,您的代码是什么样子的?您是否仅在
-performBlock:
调用中使用第二个上下文

第四,当你停在内存分配的中间时会发生什么?你的堆栈看起来像什么

对于眼前的问题,有一个无限循环。如果我不得不猜测,我会猜测您正在使用
NSManagedObjectContextDidSaveNotification
,可能与
nil
对象一起使用,并且每次保存都会启动对另一个上下文的保存,从而导致循环


查看代码将有助于解决眼前的问题。不过,我怀疑有一个更简单的解决方案可以解决您的问题。

首先,您可以对父/子系统进行大量更新,只要您注意每次保存时向磁盘写入的内容

其次,可以将两个
NSPersistentStoreCoordinator
实例指向同一个sqlite文件,并避免使用两个文件

第三,创建这些上下文时,您的代码是什么样子的?您是否仅在
-performBlock:
调用中使用第二个上下文

第四,当你停在内存分配的中间时会发生什么?你的堆栈看起来像什么

对于眼前的问题,有一个无限循环。如果我不得不猜测,我会猜测您正在使用
NSManagedObjectContextDidSaveNotification
,可能与
nil
对象一起使用,并且每次保存都会启动对另一个上下文的保存,从而导致循环


查看代码将有助于解决眼前的问题。不过,我怀疑有一个更简单的解决方案可以解决您的问题。

首先,您可以对父/子系统进行大量更新,只要您注意每次保存时向磁盘写入的内容

其次,可以将两个
NSPersistentStoreCoordinator
实例指向同一个sqlite文件,并避免使用两个文件

第三,创建这些上下文时,您的代码是什么样子的?您是否仅在
-performBlock:
调用中使用第二个上下文

第四,当你停在内存分配的中间时会发生什么?你的堆栈看起来像什么

对于眼前的问题,有一个无限循环。如果我不得不猜测,我会猜测您正在使用
NSManagedObjectContextDidSaveNotification
,可能与
nil
对象一起使用,并且每次保存都会启动对另一个上下文的保存,从而导致循环


查看代码将有助于解决眼前的问题。不过,我怀疑有一个更简单的解决方案可以解决您的问题。

首先,您可以对父/子系统进行大量更新,只要您注意每次保存时向磁盘写入的内容

其次,可以将两个
NSPersistentStoreCoordinator
实例指向同一个sqlite文件,并避免使用两个文件

第三,创建这些上下文时,您的代码是什么样子的?您是否仅在
-performBlock:
调用中使用第二个上下文

第四,当你停在内存分配的中间时会发生什么?你的堆栈看起来像什么

对于眼前的问题,有一个无限循环。如果我不得不猜测,我会猜测您正在使用
NSManagedObjectContextDidSaveNotification
,可能与
nil
对象一起使用,并且每次保存都会启动对另一个上下文的保存,从而导致循环


查看代码将有助于解决眼前的问题。但是,我怀疑有一个更简单的解决方法。

像你那样标记答案(一眼看,现在做更彻底的测试)解决了眼前的问题-我在检查中添加了if(self.managedObjectContext.persistentStoreCoordinator!=savedContext.persistentStoreCoordinator)在
NSManagedObjectContextDidSaveNotification
的通知回调中。但是,我想看看我是否能正确使用父/子。我们正在向手机本地写入大约3MB的数据,同时还删除了另外1MB的数据。我尝试在孩子身上使用
-performBlock
,但它无法用我做的所有插入更新家长。使用P/C时,最重要的一点是让你