———————————————————————————————————————————
Single Object memory management
(1) Wild hands
① defines a pointer variable, but does not assign an initial value, it randomly points to something
② The memory space pointed to by a pointer variable is freed (pointer to a zombie object)
(2) Zombie objects
Objects that have been destroyed (objects that cannot be used)
(3) NULL pointer
There is no pointer to the storage space (there is nil, that is, 0)
Sending a message to a null pointer is unresponsive and does not prompt an error
Code:
#import <Foundation/Foundation.h>
@interface Person:nsobject
-(void) run;
@end
@implementation person
-(void) run
{
NSLog (@ "run!");
}
-(void) dealloc
{
NSLog (@ "Retaincount result is 0, object memory is freed!) ");
[Super Dealloc];
}
@end
int main (int argc, const char * argv[]) {
@autoreleasepool {
Person *p=[[person Alloc]init];
NSLog (@ "[P retaincount]=%tu", [P retaincount]); Value of 1
[P run];
NSLog (@ "[P retaincount]=%tu", [P retaincount]); Value is still 1, there is currently only one using the object P, that is, himself, the number of references to the object P does not increase
[P retain];
NSLog (@ "[P retaincount]=%tu", [P retaincount]); Value of 2
[P release];
NSLog (@ "[P retaincount]=%tu", [P retaincount]); Value of 1
[P release];//Here the counter value is 0, the memory is freed
[P run]; The Run method can also be called after the memory is freed
So the problem is that the Run method is called after the object P's heap memory is freed, why is it called successfully? And now we're going to solve the problem left over from the last lesson.
First, when the P object is released (memory is freed), p is a wild pointer (Zombie object).
We know that although P is freed in the memory space of the heap, the memory space is still there and P is present in the stack area. Just P has lost the management of that part of memory. If you have to use this space at this point, and this memory space is not allocated to other programs, you can actually get the content. But if the freed space is allocated to other variables or programs, then the use is wrong.
And there is a point, that is, the above release and call the Run method, not necessarily can be hundred hundred calls, maybe 10 times there will be a call error situation, this is the danger of wild pointers. So, you can't use zombie objects to call!! The call is completely meaningless!
[P retain];
This is completely wrong and we have freed the object that P points to, so the object becomes a zombie object, and we can't resurrect it (so hard to get the value is the wrong result)
To avoid our use of zombie objects, we can do such a deal
P=nil;
After this processing, the compiler will not error when executing the following statement.
[P run];//will not execute, because P is nil
[P retain];//also does not let Count +1, or because P is nil (null value)
NSLog (@ "[P retaincount]=%tu", p.retaincount);
Dot syntax (here is equivalent to p.retaincount-->[p Retaincount])
}
return 0;
}
★ So how should we prevent the call of wild pointers?
The operation step is the above two pictures, the second picture marked the place tick, then use the wild pointer run will be an error!
Enable Zombie Objects is to turn on Zombie mode ~
The difference between nil and nil and null
Nil: First This is a null pointer, and this is an OC object, is an object value, if we set an object to NULL, we will set to nil (#define NIL ((ID) 0))
Nil: This is a class object value, and if a class object is set to NULL, then we're going to set it to nil.
Null: is a generic pointer (generic pointer) (#define NULL ((void *) 0))
NSNull: [NSNull null] is an object used in cases where nil is not available
And the last thing we need to be aware of is that when we release an object's memory space and make the object a zombie object, it's not enough [P retain]; to revive it. In the above program is reflected.
(4) Memory leak
Code:
#import <Foundation/Foundation.h>
@interface Car:nsobject
-(void) Run: (Car *) CCCC;
@end
@implementation Car
-(void) dealloc
{
NSLog (@ "Free memory! ");
[Super Dealloc];
}
-(void) Run: (Car *) CCCC
{
NSLog (@ "The car is running");
[CCCC retain];//use retain inside method to let CCCC count +1
}
@end
int main (int argc, const char * argv[]) {
@autoreleasepool {
(4) Memory leak problem
The number of ①retain and the number of release does not match
Car *car=[car New];
NSLog (@ "Car->retaincount=%tu", car.retaincount);//1
//
[Car retain];
[Car retain];
[Car retain];
//
NSLog (@ "Car->retaincount=%tu", car.retaincount);//4
//
[Car release];
//
NSLog (@ "Car->retaincount=%tu", car.retaincount);//3
It is obvious that the number of retain and the number of release are mismatched. Retaincount is not 0, then space is naturally not recovered and released.
If you do not want to let the memory leak, then you must retain + new = release (increase reference count = Reduce reference count)
The ② object was assigned nil during use.
Car *car1=[car New];
//
[Car1 retain];
[Car1 retain];
[Car1 retain];
NSLog (@ "Car1->retaincount=%tu", car1.retaincount);//4
//
Car1=nil;
[Car1 release];//In fact, these four release statements are not useful, is [nil release]; , we know that to nil send any instruction will not error, but at this time the original object car1 space is not released, so that the last car1 memory is leaked.
[Car1 release];
[Car1 release];
[Car1 release];
//
NSLog (@ "Car1->retaincount=%tu", Car1.retaincount),//0, at this time 0 does not explain any problem, not we successfully freed the memory, will not print the statement in Dealloc
③ in the method of improper use of retain
Car *car2=[car New];
[Car2 run:car2];//We will car2 ourselves as parameters into the Run method, and then in the inside of the Run method retain, then car2->retaincount=2, so say here if only release is not enough, should rele ASE two times to free up memory
}
return 0;
}
———————————————————————————————————————————
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Objective-c "single Object Memory Management"
