I know there is an autorelease pool created in the main method and all the objects that receive autorelease message get stored in this pool and get released when the pool drains out.
But it is always said to avoid autoreleasing objects to avoid memory leaks and in turn app crashes.
Then why and in which conditions should we use autoreleasepool?
Apple docs suggest that we need to use them when we are using threads so in the beginning of a thread we need to create an autorelease pool and in the end of the thread drain it but what if we are not creating an autorelease object in the complete thread then in that condition also is it necessary to create an autoreleasepool in the beginning of the thread.
Please clear out my confusion. Thanx.
An autorelease pool stores objects that are sent a release message when the pool itself is drained. Important. If you use Automatic Reference Counting (ARC), you cannot use autorelease pools directly. Instead, you use @autoreleasepool blocks.
The autoreleasepool allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C. Note: When dealing with Swift native objects, you generally will not receive autorelease objects.
@John - You shouldn't remove the autorelease pool. Create it within the thread so that it can manage autoreleased objects, but anything you wish to hang around after the thread has finished executing should be manually retained (and later manually released), or initialized using -init or copy .
A pool is created at the first brace and is automatically drained at the end of the scope. Any object autoreleased within the scope is sent the release message at the end of the scope. Let's take a look at this example: for (int i = 0; i < 100000; i++) { [self doMagicWith:i];
Your assumption is correct. When you can ensure a specific thread is never making use of autoreleased objects, that thread wouldn't need an autorelease pool.
Avoiding the autoreleasepool is a bad advice, the coin has two sides. Using autorelease'd objects carries a certain amount of overhead (although insignificant in most scenarios) that should be avoided when possible. Especially in cases where there are multiple exits to a method, or an exception can be encountered, autoreleasing helps avoiding memory leaks and makes code cleaner.
Be aware though, that this means nothing on that thread can use autorelease, including any frameworks you may call. There are situations where this is the case, such as in a classic producer/consumer scenario. You have a producer that creates objects, dispatches them to the main threads runloop, and can register them in the main threads autoreleasepool consequently.
In general, I would not recommend creating a thread where significant work is carried out (besides a simple, long running computation) without an autoreleasepool.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With