I'm using ARC and NSCache which is created and stored on my app delegate. Then I call it from the controllers trough the app delegate. The NSCache stores images as they are loaded from an url and the memory usage goes up really quick. When I check the profiler for real memory usage, my app reaches even 320 MB of memory usage but on allocations it says it has just allocated 20-30 MB.
On my app delegate I set the cache as follows (it is an ivar):
cache = [[NSCache alloc] init];
[cache setCountLimit:100];
[cache setTotalCostLimit:1500000];
[cache setEvictsObjectsWithDiscardedContent:YES];
I implemented a button to experiment with NSCache and when I click on it it calls:
- (IBAction)eraseCache:(id)sender {
[[appDelegate cache] removeAllObjects];
}
On the profiler, the memory used does not go down, but it actually starts to get the images again, so I know the objects where removed. How can I release this memory usage at will using ARC? How can I get the size of my cache to know when to release it?
In ARC, once there are no pointers to an object, it's automatically released. If the only pointers you had to the object were in the cache, then they have been released.
Note that you don't actually have to remove the objects; if you assign the pointer to a new object (with the result that it no longer points at the old object) then the old object is deallocated.
Ex:
NSArray *array = [NSArray new];
array = [NSArray new]; //the original array gets deallocated because nothing points to it.
From the NSCache Class Reference:
The NSCache class incorporates various auto-removal policies, which
ensure that it does not use too much of the system’s memory. The
system automatically carries out these policies if memory is needed by
other applications. When invoked, these policies remove some items
from the cache, minimizing its memory footprint.
Related
I just ran into a problem.I use NSMutableArray to keep the Ad ids that need to be loaded. When one id is preloaded, I remove it from the array. Then I find out that, after remove, the unit id became a zombie.
I tried to reproduce this, and I find out that when the Ads id was pulled from array, it is not a zombie.It just become zombie after removed from array. But, there is still a NSString* refer to it, how can this happen? And If it will become zombie at this point, it should become zombie every time. But it only happens occasionally.
-(void)preloadNextRewardVideo
{
if([_allRewardVideoAds count])
{
NSString* adsName = [_allRewardVideoAds objectAtIndex:0]; //the element is not a zombie here
GADRewardBasedVideoAd* ads = [self ensureRewardVideo:adsName];
if(![ads isReady])
{
_currentRewardVideoName = adsName;
[_allRewardVideoAds removeObjectAtIndex:0];
GADRequest *request = [GADRequest request];
[ads loadRequest:request withAdUnitID:adsName]; //here, adsName is a zombie
_isRewarLoading = YES;
}
}
}
It's worth taking a close look at cocoa's memory management policies. The thing here (it seems to me) is that when your code assigns the string adsName, the object the preloadNextRewardVideo method is part of doesn't take ownership of the string-object that adsName is pointing at ('ownership' in this context means either allocating and initializing space for it through alloc/init, new, copy, etc, or sending it an explicit retain message). All you have is a local variable that points at a string-object owned by the _allRewardVideoAds array. Yes, making the assignment increases the retain count, but that retain is autoreleased, and limited to the scope of this method. As soon as this method ends, nothing is going to own that string-object, and it will deallocate.
This would not be an issue (and would not create the NSZombie flag) except that you just sent adsName to a different object (GADRewardBasedVideoAd* ads) that I'm guessing does not retain it either. Of course, ads is also autoreleased (nothing owns it outside of this method), but what is that, a race-condition over whether ads or adsName is deallocated first? I suspect you do have a race-condition because NSZombie only shows up sometimes, but I don't know enough about the internal mechanisms of autorelease to know how that might work.
I think NSZombie is just telling you that you have an object that is:
in use by an external object, and
due to be destroyed shortly though autorelease.
ARC is anticipating a problem, and using NSZombie to let you know.
You could fix this either by using the property setter (e.g. use self.currentRewardVideoName = adsName) which retains the string-object globally for this object, or by locally copying it (NSString* adsName = [[_allRewardVideoAds objectAtIndex:0] copy]) which makes sure that your object owns the string to the end of the method.
Since you don't enable ARC that means you need to manually manage the memory by yourself. Since you don't enable ARC that means you need to manually manage the memory by yourself. Even though most of APIs will return an auto released object from a method but that's not always be the case.
For this case, NSArray retains the objects contained in itself so it may not need to return an auto released object from objectAtIndex: method since it should be retained by itself as an optimization. In this case I suggest you to call retain the object when you get it from the array and release it before the end of this method. That would help for this case.
Should I always check if [[NSArray alloc] init…] (or with any other collection class) returns nil? The Apple docs say that objects may return nil if allocation or initialisation fails. I don't know when initialising may fail with NSArray, but I guess that allocation may fail with insufficient memory. And because I'm developing for iOS, that may become a regular problem. Do I have to about that and check every time I want to create a new array, or will my app fail because of memory constraints (assuming worst-case situation, of course) and checking for nil is just a waste of cycles?
Currently, I'm only checking when I allocate a mutable collection with a large predetermined capacity (e.g. [NSMutableArray arrayWithCapacity: 1000]) or an immutable collection with lots of objects (over a thousand).
Thank you.
No, not with NSArray. NSArray is a linked list using structs, so it does not malloc much behind the scenes. Checking for nil, at least with NSArray is rather pointless.
However, if you were using a collection class like CCArray, from cocos2d, for example then checking for nil with a large array could be beneficial.
Still, the size of a pointer on iOS is 8 bytes, and even a C-Array of 1000 elements is only 8 KB of RAM. In most cases, you won't be using enough memory to the point where you will run out.
Also note that if you come to the point where your application is running low on memory, there are many delegate methods that you can register to to be warned about this and fix it.
I have prepared a class for storing data retrieved from db, and let's say I have 10 vars in it. What if I will reuse this class for different views and each view will use a different quantity of variables.
tableViewCell will pop-up 3 vars.
View1 will pop-up 6 vars.
View2 will pop-up 10 vars.
Will the unused data cause memory leaks?
A memory leak only happens when you delete all pointers to the memory before freeing it. If you reuse your data structure, you might have some unused memory, but it won't be a leak unless you never free it when the pointers go away (leaving you no way to free it ever again).
Unused variables have nothing to do with memory leaks. You want to see a memory leak?
- (void)leakABunchOfMemory {
for (int i = 0; i < 1000000000; i++) {
NSMutableString *usedButNotUsedCorrectly = [[NSMutableString alloc] initWithFormat:#"%d", i];
}
}
That's a memory leak. An object is created with every [NSMutableString alloc], and none can never be destroyed because you lose your reference to them as soon as that iteration of the loop ends. They just go on existing and taking up space, like text-based zombies that hunger for the RAM of the living. To avoid leaks in Objective-C code, follow the memory management rules, and the equivalent rules for any other libraries you use.
I am calling a function repeatedly with a loop, and the loop runs inside of a thread. The thread has an autorelease pool.
I have the following code inside that function:
NSXMLDocument* undoXML;
NSData* undoData = [NSData dataWithContentsOfFile:undoFilePath];
undoXML = [[NSXMLDocument alloc] initWithData:undoData options:NSXMLDocumentTidyXML error:&err];
NSData* undoData2;
undoData2 = [undoXML XMLData];
[undoData2 release];
[undoXML release];
I'm getting the following strange results:
My program is leaking memory every time this function is called by the loop.
When I add the following code to the function:
NSData* undoData3;
undoData3 = [undoXML XMLData];
[undoData3 release];
My program leaks even more memory than before.
I'm really confused and I badly need help figuring out what's going on. Maybe my autorelease pool isn't working correctly? Why is this happening?
Are you sure it is leaking? Or is it simply growing in size?
What does your loop look like and how is the autorelease pool integrated into it?
The autorelease pool must be inside the loop or your loop will just build up tons of memory over time. That the leaks instrument doesn't show leaks indicates that you have violated the memory management rules or your loop is incorrect.
Try running Instruments on your project w/ the leak detection settings. This should identify exactly where your leak is occurring (even in the system libraries).
Run -> Run With Performance Tool -> Leaks
undoData should be preset to be autoreleased (according to naming convention dataWithContentsOfFile: returns an autoreleased object). But unless you have your own autorelease pool, nothing that is set to autorelease will actually be deallocated until the active pool is drained (i.e. sometime after your function returns).
Your thread may have its own autorelease pool, but unless you are creating one inside your own function, nothing will be deallocated until after your function exits.
If you want to trigger the draining of autoreleased objects in the middle of a function (say once per loop), you need to manage your own autorelease pool.
while(looping) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// do stuff that produces autoreleased objects
[pool drain];
}
Also, per cobbal's comment on your question, it looks like you should not be releasing undoData2 (or undoData3). Based on the naming convention -[NSXMLDocument XMLData] should be returning an autoreleased object.
If you have access to the source code of the NSData class you should look at what objects are being instantiated when undoData3 is created. I say this because you create the object and immediately destroy it. The issue must be that memory is being allocated inside the class but not being deallocated in it's destructor.
Here is the gist of some code I'm writing. I'm concerned that I am not properly addressing the retain/release issues with the array class method on NSMutableArray. Is the following actually leaking memory?
for(a while) {
// do stuff
NSMutableArray *a = nil;
// do stuff
if (!a) {
a = [NSMutableArray array];
}
} // for(a while)
You wouldn't leak memory in this code, and releasing the array yourself will cause a crash when the array is autoreleased at the end of the run loop.
Most Cocoa classes provide a couple of ways of making a new object, and are very consistent with this convention:
[[NSSomeObject alloc] init] : you are responsible for releasing the object (instance method).
[NSSomeObject someObject] : the object will be autoreleased for you, usually at the end of the run loop (class method). It's roughly equivalent to [[[NSSomeObject alloc] init] autorelease].
The proper use of the instance method would be:
a = [[NSMutableArray alloc] init];
// do stuff
[a release];
The proper use of the class method would be:
a = [NSMutableArray array];
// do stuff, array is in the autorelease pool
Note that Apple has recommended you stay away from the convenience methods as much as possible to improve performance. This is controversial advice, may not save much processor time, and separates the alloc-init from the release on an object you may not actually care much about keeping.
From the Cocoa Memory Managment Rules:
You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.
Therefore with the line:
a = [NSMutableArray array];
you do not take ownership of the array, and it will be passed to you autoreleased. The memory will be handled for you automatically by the autorelease pool, and once it is no longer being used, it will be released for you. If you want to keep the array outside the current event, however, you must retain it, otherwise it will be released for you.
Yes, if you want it to stick around.
The returned object is an autoreleased object which will get deallocated when its autorelease pool gets purged.
All the array class methods that begin with "array" return these types of autoreleased objects.
Read this doc by Apple.
That's valid. It may help to just manage things manually when you have questions, to learn.
There is a convention:
init prefixes (init, initWithString:) indicate a retain count of 1, where
objectname prefixes (string, stringWithString:) indicates an autoreleased object
I have had the habit, for years, to release what I can at the call site, rather than pushing it to be autoreleased. Some autorelease issues then become painfully difficult to track down. Sure, autorelease is a convenience to the programmer in this case (provided nothing goes wrong), but adversely affects reuse, clarity, and performance (moreso in large codebases/programs).