How does the NSAutoreleasePool autorelease pool work?

9 Solutions Collect From Internet About “How does the NSAutoreleasePool autorelease pool work?”

Yes, your second code snippit is perfectly valid.

Every time -autorelease is sent to an object, it is added to the inner-most autorelease pool. When the pool is drained, it simply sends -release to all the objects in the pool.

Autorelease pools are simply a convenience that allows you to defer sending -release until “later”. That “later” can happen in several places, but the most common in Cocoa GUI apps is at the end of the current run loop cycle.

NSAutoreleasePool: drain vs. release

Since the function of drain and release seem to be causing confusion, it may be worth clarifying here (although this is covered in the documentation…).

Strictly speaking, from the big picture perspective drain is not equivalent to release:

In a reference-counted environment, drain does perform the same operations as release, so the two are in that sense equivalent. To emphasise, this means you do not leak a pool if you use drain rather than release.

In a garbage-collected environment, release is a no-op. Thus it has no effect. drain, on the other hand, contains a hint to the collector that it should “collect if needed”. Thus in a garbage-collected environment, using drain helps the system balance collection sweeps.

As already pointed out, your second code snippet is correct.

I would like to suggest a more succinct way of using the autorelease pool that works on all environments (ref counting, GC, ARC) and also avoids the drain/release confusion:

int main(void) {
  @autoreleasepool {
    NSString *string;
    string = [[[NSString alloc] init] autorelease];
    /* use the string */
  }
}

In the example above please note the @autoreleasepool block. This is documented here.

No, you’re wrong. The documentation states clearly that under non-GC, -drain is equivalent to -release, meaning the NSAutoreleasePool will not be leaked.

I found this link gave the best explanation on when and how to use NSAutoReleasePool: AutoReleasePool

yeah your code is perfect, if you’d be using garbage collecting it would be enough to just set the string to nil when you are done with it. Garbage collecting is not good for the performance of your app so I would not recommend using it 😛

What I read from Apple:
“At the end of the autorelease pool block, objects that received an autorelease message within the block are sent a release message—an object receives a release message for each time it was sent an autorelease message within the block.”

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html

sending autorelease instead of release to an object extends the lifetime of that object at least until the pool itself is drained (it may be longer if the object is subsequently retained). An object can be put into the same pool several times, in which case it receives a release message for each time it was put into the pool.

Yes and no. You would end up releasing the string memory but “leaking” the NSAutoreleasePool object into memory by using drain instead of release if you ran this under a garbage collected (not memory managed) environment. This “leak” simply makes the instance of NSAutoreleasePool “unreachable” like any other object with no strong pointers under GC, and the object would be cleaned up the next time GC runs, which could very well be directly after the call to -drain:

drain

In a garbage collected environment, triggers garbage collection if memory allocated since last collection is greater than the current threshold; otherwise behaves as release.

In a garbage-collected environment, this method ultimately calls objc_collect_if_needed.

Otherwise, it’s similar to how -release behaves under non-GC, yes. As others have stated, -release is a no-op under GC, so the only way to make sure the pool functions properly under GC is through -drain, and -drain under non-GC works exactly like -release under non-GC, and arguably communicates its functionality more clearly as well.

I should point out that your statement “anything called with new, alloc or init” should not include “init” (but should include “copy”), because “init” doesn’t allocate memory, it only sets up the object (constructor fashion). If you received an alloc’d object and your function only called init as such, you would not release it:

- (void)func:(NSObject*)allocd_but_not_init
{
    [allocd_but_not_init init];
}

That does not consume any more memory than it you already started with (assuming init doesn’t instantiate objects, but you’re not responsible for those anyway).