The NSObject protocol states the following three methods for manipulating a counter to increase or decrease its value retain increasing reference count release decreasing reference count AutoRelease later when the autorelease pool is cleansed decrement the reference count

To avoid inadvertently using an invalid object, the pointer is usually cleared after release. This ensures that there are no Pointers to highly invalid objects, often referred to as dangling Pointers. If the property is decorated with “strong”, the set property value is retained.

-(void)setFoo:(id)foo{
  [foo retain];
  [_foo release];
  _foo = foo;
}
Copy the code

This method keeps the new value and frees the old value, then updates the instance variable to point to the new value. Order is important. If the old system is released before the new value is retained, and both values point to the same object, a restrictive release operation can cause the object to be permanently reclaimed. A subsequent retain operation cannot revive the completely reclaimed object, and the instance variable becomes a suspended pointer. A common problem with the reference counting mechanism is the return cycle, which refers to multiple objects in a loop. This causes a memory leak because the retention count of objects in the loop does not drop to zero. For each object in the loop, at least one other object references it, and the garbage collector will reclaim all the objects that reference each other. However, OC reference technology architecture does not enjoy this convenience, and usually uses weak Reference to solve the problem, so as to avoid memory leakage.

The reference counting mechanism manages memory by incrementing and decrementing counters. After an object is created, its retention count is at least 1. If the retention count is positive, the object continues to live. When the retention count drops to 0, the object is destroyed. During the object’s life, the rest of the objects retain or release the object by reference. The retention and release operations increase and decrease the retention count, respectively.

An ARC environment automatically executes retain Release autorelease dealloc, so it is illegal to call these methods after ARC, and programmers don’t need to worry about memory management. Using ARC to program saves a lot of boilerplate code from your classes. ARC manages object lifetimes basically by inserting hold and release operations where appropriate. In an ARC environment, the memory management semantics of variables are always represented by method names. ARC has identified this as a rule that developers must follow. ARC is only responsible for managing memory for Objective-C objects. In particular, CoreFoundation objects are not managed by ARC and developers must call CFRetain/CFRelease when appropriate.

In the dealloc method, all you need to do is release references to other objects and unsubscribe from the subscribed keyvalue observations or NSNotificationCenter. If the object holds system resources such as file descriptors, you should write a special method to release such resources. Such classes agree with their consumers that they must call the close method when they run out of resources. Methods that perform asynchronous tasks should not be called in dealloc; Methods that can only be executed in normal state should also not be called in dealloc because the object is already in the recycling state.

Set some references to weak to avoid repeated references. Weak references may or may not be automatically cleared. Auto-clearing is a new feature introduced with ARC, implemented by the Runtime, which allows you to read data from weak references with auto-clearing because they don’t point to objects that have already been reclaimed.