Ownership of object and reference counting

To indicate the number of owners using objects, those objects are given a reference count.

At the beginning, the reference count of the object is 1. This happens because the function creating the object is going to use that object. When any entity needs to claim an ownership of the object, since that entity is going to access and use that object, it sends a retain message to it and its retain count is incremented by 1. When an entity is finished with the object, it sends the release message to the object and its retain count decrements by 1. As long as this object's reference count is higher than zero, some "things" are using it. When it comes to zero, the object is no longer useful for any of those "things", and it can be safely deallocated.

Let's return to the example with the object owned by an array. Explanations are given in the following code comments and diagram:

int main(int argc, char *argv[]) {

  SomeObject *myOwnObject;
  // myOwnObject is created in main
   myOwnObject = [[SomeObject alloc] init];
  // myOwnObject has retain count equal to 1

// myOwnObject can be used by other objects
NSMutableArray *myArray;
// add my object to myArray    
myArray = [[NSMutableArray alloc] initWithObjects:myOwnObject, nil];
//inside myOwnObject got another retain message
//and now its retain count equal 2
    
// main does not need myOwnObject any more
[myOwnObject release];
// release decrements retain count
// and now myOwnObject retain count now is 2-1 = 1

// but myOwnObject still is needed inside the array
[anotherObj usingArray: myArray];

[myArray release];
// on array destruction every object inside array gets release message

//myOwnObject retain count decreases this time to 0 and myOwnObject will be deleted together with the array

The following diagram illustrates the principle of reference counting:

Forgetting to send a release message to an object before setting a pointer to point at something else will guarantee you a memory leak. In order to create an object before it's initiated, a chunk of the OS memory is allocated to store it. Also, if you send a release statement to an object, which was not previously sent, a retain statement is sent to the object. This will be considered as a premature deallocation, where the memory previously allocated to it is not related to it anymore. A lot of time is spent on debugging these issues, which can easily become very complex in large projects. If you don't follow some solid principles for memory management, you can often forget and quickly find yourself getting stuck for hours checking every retain and release statement. Even worse is if you're going through someone else's code, and they mess things up. Going through to fix memory management issues in someone else's code can take forever.