Iphone (object-c) memory management (3) Half of Effective Memory Management

Now I am engaged in iphone development. I have never been very familiar with the object-c memory management mechanism. I can see that apple's official documents are well written and I have not found any translation articles. So I translated it by the way when I was learning it. My English is not very good, and the ability to organize words is even better. I hope you can point out the poor reading, I shall correct the translation in the future. For the first translation, you are welcome to shoot bricks. Don't beat me to death !!!

The words LPSTUDY in the article indicate that they are my personal understanding and may be incorrect. Please kindly advise.

Original article URL:

[Html]View
Plaincopy

1. Http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW1

Do not use dealloc to manage scarce resources

 

You should not use the dealloc method to manage scarce resources such as file descriptors, network connections, and caches. In particular, you should not take the design class for granted that dealloc will be triggered in what you think. The trigger of dealloc may be delayed or avoided due to bugs or program crashes.

 

On the contrary, if you have a class instance to manage scarce resources, you should design your program to tell the instance variable to clean up resources when appropriate, then call dealloc to release the instance variable. If dealloc is not called, you will not suffer from serious problems.

 

When you manage resources in the dealloc method, problems may occur. For example:

1. Smooth dependency of object graph destruction

The object graph destruction mechanism is inherently not smooth. Although you may expect a specific sequence, it is generally unreliable. If an object falls into the Auto Release pool improperly, the destruction sequence of the object may change, which leads to unexpected problems.

2. No recovery of scarce resources

Memory leaks need to be solved, but they do not immediately cause fatal problems. If a scarce resource is not released when you want it to be released, you may encounter serious problems. For example, if your program runs out of file descriptors, you cannot store data.

3. The cleanup logic is executed in the wrong thread.

If an object is put into the automatic release pool at a wrong time, it may be released without worrying about which thread pool it happens to be in. This may be fatal because this object is only accessed by another thread.

 

LPSTUDY:

To be honest, this paragraph is too theoretical to read. My understanding is: when you manage scarce resources, do not do it in dealloc. For example, if you want to release the file descriptor in dealloc, but due to a program bug, dealloc is not executed, that is, the file descriptor is not released. If the dealloc needs to be executed multiple times, many file descriptors that you want to release are not released. This is obviously incorrect. Of course there are three types of dealloc problems mentioned above. I just gave the second example. In general, do not use dealloc to manage scarce resources. In other words, do not trust dealloc execution too much.

 

Collection class owns the objects they contain

When you add an element to a collection class (such as an array, Dictionary, or set), the collection class has this element. When you call the remove Method of the Collection class or the collection class is released, the collection class releases the ownership of the element. Therefore, if you want to create an array, you can use the following methods:

NSMutableArray * array = <# Get a mutable array #>;

NSUInteger I;

//...

For (I = 0; I <10; I ++ ){

NSNumber * convenienceNumber = [NSNumber numberWithInteger: I];

[Array addObject: convenienceNumber];

}

In this case, alloc is not called, so there is no need to call release. You do not need to call the retain method either, because array has already been done.

 

NSMutableArray * array = <# Get a mutable array #>;

NSUInteger I;

//...

For (I = 0; I <10; I ++ ){

NSNumber * allocedNumber = [[NSNumber alloc] initWithInteger: I];

[Array addObject: allocedNumber];

[AllocedNumber release];

}

In the preceding example, you call the alloc method. Therefore, after addobject, you need to call the release method. In addobject, array has called the retain operation on allocedNumber.

 

If you want to better understand the above mechanism, please look at it from the perspective of Collection class designers. Because you want to ensure that your collection class does not depend on whether the external incoming elements are released at a later time, you call the retain operation when the elements are passed in. If they are removed, you call the release operation to balance the retain you added. In the dealloc method of the Collection class, you should call the release method for all the remaining elements.

 

The ownership policy is implemented by reference counting.

The mechanism is implemented by reference count. Each object has a reference count.

· When you create an object, its reference count is 1

· When you send a retain message to this object, its reference count increases by 1

· When you send a release message, the reference count minus 1

When you send an autorelease message, its reference count will be reduced by 1 at a certain time in the future.

· If the reference count of an object is 0, it will be released

 

Important:

You should not explicitly observe the reference count value of the object. The result may be incorrect, mainly because the system framework may call the retain operation without your knowledge. When debugging memory management problems, you should always ensure that your code strictly complies with the rules of object ownership.