NS自动释放池

发布于 2024-09-14 12:31:01 字数 110 浏览 6 评论 0原文

我耗尽了自动释放池。警告***尝试弹出未知的自动释放池意味着自动释放池是通过不同的方法创建和耗尽的 - 这很好。

但这是否意味着这样的池没有被排空？有解决办法吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

穿透光 2024-09-21 12:31:01

@itaiferber 是不正确的，他链接到的开发博客文章也是如此。

NSAutoreleasePools不是在堆栈上创建的。就像所有其他 Cocoa 对象一样，它们在堆上分配。

我认为混乱的来源是在文档中它说：

每个线程（包括主线程）维护自己的 NSAutoreleasePool 对象堆栈（请参阅“线程”）。创建新池时，它们会被添加到堆栈的顶部。当池被释放时，它们将从堆栈中删除。

文档中提到的“堆栈”不是调用堆栈，而是一个堆栈数据结构。这意味着，如果您有“自动释放池1”，然后创建第二个自动释放池，然后自动释放一个对象，则当第二个自动释放池耗尽时，该对象将被释放。

总之：我们非常欢迎您在一种方法中创建自动释放池并在另一种方法中耗尽它，只要您了解这样做对内存的影响。（这是否是一个糟糕的设计完全是另一个问题）

如果您最终没有耗尽池，那么当父自动释放池被耗尽时它将为您耗尽。

如果您释放的自动释放池不是堆栈顶部的，则会导致堆栈上位于其上方的所有（未释放的）自动释放池及其所有对象被释放。如果您在完成后忽略将释放发送到自动释放池（不推荐这样做），那么当它嵌套的自动释放池之一被释放时，它就会被释放。

因此，如果您的自动释放池堆栈如下所示：

 _____
|  1  |  <--- most recently allocated pool
|-----|
|  2  |
|-----|
|  3  |  <--- least recently allocated pool
 -----

然后您排空池 3，池 2 和 1 也将自动排空。我猜这就是您的代码中发生的情况。您正在创建“池 1”，然后当“池 3”耗尽时它会自动耗尽，然后您尝试自己耗尽池 1，但它不再有效，并且您“尝试弹出一个未知的”自动释放池”。

如果您尝试在 GUI 应用程序中保留自动释放池，这个问题尤其明显。在此类应用程序（基于 UIKit 或 AppKit）中，运行循环将在每次循环时创建和销毁自动释放池，这意味着您在循环迭代期间创建的任何自动释放池都将在下一次循环出现时销毁大约。

有关这方面的更多具体信息，请参阅内存管理编程指南的整个部分专门介绍自动释放池。

@itaiferber is incorrect, as is the Dev Blog post he links to.

NSAutoreleasePools are not created on the Stack. They are allocated on the heap, just like all other Cocoa objects.

I think where the confusion comes from is that in the documentation it says:

Each thread (including the main thread) maintains its own stack of NSAutoreleasePool objects (see “Threads”). As new pools are created, they get added to the top of the stack. When pools are deallocated, they are removed from the stack.

The "stack" referred to in the documentation is not the call stack, but a stack data structure. This means that if you have "autorelease pool 1", and then create a second autorelease pool, and then autorelease an object, the object will be released when the second autorelease pool is drained.

In summary: you are perfectly welcome to create an autorelease pool in one method and drain it in another, as long as you understand the memory implications of doing so. (Whether or not this is bad design is another question entirely)

If you end up not draining the pool, it will be drained for you when a parent autorelease pool is drained.

If you release an autorelease pool that is not the top of the stack, this causes all (unreleased) autorelease pools above it on the stack to be released, along with all their objects. If you neglect to send release to an autorelease pool when you are finished with it (something not recommended), it is released when one of the autorelease pools in which it nests is released.

So if your autorelease pool stack looks like:

 _____
|  1  |  <--- most recently allocated pool
|-----|
|  2  |
|-----|
|  3  |  <--- least recently allocated pool
 -----

And you then drain pool 3, pools 2 and 1 will automatically be drained as well. I'm guessing this is what's happening in your code. You're creating "pool 1", and then it's getting automatically drained when "pool 3" gets drained, and then you're attempting to drain pool 1 yourself, but it's no longer valid, and you are "attempting to pop an unknown autorelease pool".

This problem because especially apparent if you're trying to hang on to autorelease pools in a GUI application. In such applications (UIKit or AppKit based), the run loop will create and destroy an autorelease pool on every pass of the loop, which means that any autorelease pool you create during an iteration of the loop will be destroyed the next time the loop comes around.

For much more specific information on this, there's an entire section of the Memory Management Programming Guide devoted to autorelease pools.

回复收藏 0 原文

~没有更多了~