【问题标题】:How is a thread related to its NSAutorelease pool?一个线程与它的 NSAutorelease 池有什么关系?
【发布时间】:2012-01-31 15:45:03
【问题描述】:

我对 NSAutorelease 池的工作原理有一个大致的了解。 我们在其中有自动释放的对象,并且在调用 drain 方法时。 检查池中保留计数为 +1 的对象,并因此被释放。

但我不确定的是。 我们在主线程中创建 NSAutoRelease 池对象,并为每个线程创建一个对象。 线程如何与该特定池相关。 如果我们在一个线程中创建两个或多个自动释放池会发生什么。

我们只是创建池对象并在工作完成后将其排出。 它不像我们得到一个单身人士或其他东西。

那么线程如何到达那个特定的池?

我所说的保留计数 1 的场景解释。[略有错误,请阅读编辑]

  • Obj A 有一个方法 createAndReturn。
  • createAndReturn 创建一个对象 autorel_obj 并返回它。

现在它不能只释放它,因为它必须返回它。 所以它会自动释放它并返回。

因此 autorel_obj 将在自动释放池中。 现在说 objB 调用了 ObjA 的 createAndReturn。

并获取 autorel_obj 并保留它,否则自动释放池将耗尽它。 现在当它被 objB 保留时,它的保留计数为 2。

[这里是不正确的部分,编辑]

自动释放池只能释放 autorel_obj,直到它也被 objB 使用。 这就是为什么在 objB 也释放它并且它的保留计数变为 '1' 之前,它不能被释放。

所以通过retainCount 1,我的意思是将它发送到池的对象是唯一拥有它的对象。

关于池和线程的关系,Firoze Lafeer 的回答很有帮助。

编辑以保留第 1 个场景: 正如 Firoze 正确指出的那样, 我之前对保留计数 1 的解释需要更改。

autorel_obj 只会在池耗尽时被释放,因此它的保留计数将减少 1。 它不会从内存中释放。 一旦 autorel_obj 的所有其他所有者 obj 释放它,它的保留计数变为 0。 那么只有它会从内存中释放出来。

抱歉给大家带来了麻烦,感谢 Firoze 的更正。

【问题讨论】:

  • 简而言之;自动释放池和线程是完全正交的;不相关。

标签: objective-c ios nsthread nsautoreleasepool


【解决方案1】:

检查池中保留计数为 +1 的对象,并因此被释放。

我不确定我是否完全理解该陈述,但对我来说这听起来不正确。自动释放没有任何条件。如果您自动释放一个对象,它在池耗尽时被释放,而不管其当时的保留计数(即使该对象已经被释放!)最好考虑“自动释放”作为“延迟发布”。

至于另一个问题,每个线程都维护自己的自动释放池堆栈。每个池与一个(且只有一个)线程相关联。

给定的池与哪个线程相关联?答案是创建池的线程。如果您创建一个已经存在的新池,则新池“嵌套”在现有池中。在该新池范围内自动释放的对象将在该池耗尽时(该池范围结束时)被释放。

希望对你有帮助?

编辑

解决您的编辑问题:

你的解释不正确。自动释放池可以并且确实在对象耗尽后立即释放它。它不会等待 objB 先释放它。它甚至不知道您的示例中可能保留了哪些其他对象 autorel_obj 。我认为您将释放与释放混淆了。

所以场景是这样的:

  • createAndReturn 分配和自动释放 autorel_obj(保留计数为 +1
  • objB 保留 autorel_obj(保留计数 +2
  • 池被耗尽,autorel_obj 被池释放(保留计数+1
  • 在未来的某个时候,objB 会发布 autorel_obj(保留计数 0
  • autorel_obj 被释放

因此,池不知道也不关心其他对象可能保留了它正在释放的对象。它会在耗尽时无条件地释放。这可能不会导致对象立即被释放,但这不是池的问题。

【讨论】:

  • 谢谢,这绝对有帮助。
  • 现在检查。我有点晚了。我尝试编辑我的评论并仅在此处给出答案,但由于 cmets 中存在字符限制,因此无法回答。
  • 知道了。我会说你的解释仍然不正确。我编辑了我的答案以包含它。
  • 哦..感谢您的澄清..我真的很困惑释放和释放。所以自动释放池只是释放它,只是保留计数下降?这意味着 obj 仍在内存中。当其他对象释放它并且保留计数下降到0时,它最终从内存中删除并调用它的dealloc。非常感谢 .. 消除了混乱 ..lemme 现在再做一次编辑。
猜你喜欢
  • 1970-01-01
  • 2016-05-21
  • 1970-01-01
  • 2019-11-28
  • 2012-09-03
  • 1970-01-01
  • 2011-03-28
  • 2019-07-22
  • 2012-03-12
相关资源
最近更新 更多