即使在ARC下，在GCD中使用Realm时也必须使用显式自动释放池 [英] Do we have to use explicit autorelease pool when using Realm in GCD even under ARC

问题描述

在Realm的文档中有这样的说法:

It is said in Realm's doc:

使用Grand Central Dispatch访问Realm时，您可能还会看到此问题.当领域最终进入调度队列的自动释放池中时，可能会发生这种情况，因为执行代码后，这些池可能在一段时间内不会耗尽.在释放RLMRealm对象之前，无法重用Realm文件中的中间数据版本. 为避免此问题，从调度队列访问Realm时应使用显式的自动释放池.

You may also see this problem when accessing Realm using Grand Central Dispatch. This can happen when a Realm ends up in a dispatch queue’s autorelease pool as those pools may not be drained for some time after executing your code. The intermediate versions of data in the Realm file cannot be reused until the RLMRealm object is deallocated. To avoid this issue, you should use an explicit autorelease pool when accessing a Realm from a dispatch queue.

这是否意味着即使在ARC下，我们也必须每次在GCD中都使用显式自动释放池?有人可以发布代码示例吗?这很重要，但是官方文档并没有强调太多

Does this mean that we must use explicit autorelease pool everytime in GCD even under ARC? Can someone post a code sample? This is kind of important, but the official documentation does not emphasize it so much

推荐答案

您实际上不必每次都使用显式的自动释放池.它与您执行大量并发事务并且很容易陷入跟踪多个即时版本的风险的情况下更为相关.或者，当您要确保通过释放所有打开的访问器来确保在应用程序的生命周期内关闭Realm文件时.

You don't really have to use an explicit autorelease pool every time. It is more relevant for scenarios where you do a lot of concurrent transactions and could easily run into the risk of tracking to many immediate versions. Or when you want to make sure that you close the Realm file in the lifetime of your app by releasing all open accessors to it.

与一般的最佳实践相比，文档在这一点上的理解更多是为了了解技术局限性，并提示一旦遇到类似问题，如何解决该问题.当然，您总是可以这样做，并且不一定会伤害您(例如，如果您有锤子，一切都看起来像钉子.")，但不一定必须这样做.

The docs are at this point more to understand as a making aware of technical limitations and a hint how to resolve that once you hit an issue like that than a general best practice. Sure, you could always do that and it wouldn't necessarily hurt you (à la "If you have a hammer, everything looks like a nail."), but you wouldn't necessarily have to do it.

这并不是每个人都需要的复杂含义.了解显式自动释放池需要对ARC进行更深入的了解，这不是一般要求.如果您有想法，可以如何更好地解决，那么欢迎您提供反馈.

The extra complication of what this exactly means is not required for everyone. Understanding explicit autorelease pools needs a deeper understanding of ARC that is not a general requirement. If you have ideas, how that could be resolved in a better way, your feedback is more than welcome.

在线程间使用领域举一个例子，在后台队列中插入一百万个对象:

The section Using a Realm Across Threads gives an example for that, inserting a million objects in a background queue:

dispatch_async(queue) {
  autoreleasepool {
    // Get realm and table instances for this thread
    let realm = try! Realm()

    // Break up the writing blocks into smaller portions
    // by starting a new transaction
    for idx1 in 0..<1000 {
      realm.beginWrite()

      // Add row via dictionary. Property order is ignored.
      for idx2 in 0..<1000 {
        realm.create(Person.self, value: [
          "name": "\(idx1)",
          "birthdate": NSDate(timeIntervalSince1970: NSTimeInterval(idx2))
        ])
      }

      // Commit the write transaction
      // to make this data available to other threads
      try! realm.commitWrite()
    }
  }
}

通常具有合理数量的对象创建，例如在单独的自动释放池中创建对象，因为您无法使用ARC真正预测何时将释放对象，因此您有明确的时间点，何时将对象释放最晚，这使您的程序对您和其他人<确定性>确定性地理解.

It generally makes sense to have object creations in a number like that in a separate autoreleasepool as you can't really predict with ARC when the object releases will happen and so you have an explicit point in time, when they will happen latest, which makes your program more deterministically to understand for you and other humans.

这篇关于即使在ARC下，在GCD中使用Realm时也必须使用显式自动释放池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！