Edit me

-finalize runs automatically before -dealloc

When the -retainCount is decremented to zero via -release, an object gets the -finalize message first before -dealloc. If the retainCount remains unchanged throughout -finalize, then -dealloc is called. It is guaranteed that -finalize is only called once.

During -finalize all @properties with pointers (e.g. void *) or objects (e.g. NSArray *) will be cleared.

So -finalize is used to free resources and cut links to other objects. Objects that are cleared by -finalize will be released with -autorelease and not with -release.

-dealloc will ideally at most contain -release calls and [super dealloc]. Anything else can be done in -finalize. The idea is, that a finalized object is still useable in the object hierarchy, but not active anymore. A good example, where this is useful, is a window controller, where the window close button has been clicked. It may still redraw, but it doesn’t react to any event actions any more.

-performFinalize runs -finalize on demand

You can use -performFinalize to finalize an object “manually”, but you shouldn’t call -dealloc manually on a reference counted object.

Your -finalize must call [super finalize]

If you write a -finalize method call [super finalize] so that NSObject can clean up any properties.

Write -finalize/-dealloc portably

If you use -finalize, you will be incompatible with non-ARC Apple. This can be remedied, by structuring your -finalize/-dealloc code like this:

- (void) _finalize
{
}

- (void) finalize
{
  [self _finalize];

   [super finalize];
}

- (void) dealloc
{
#ifndef __MULLE_OBJC__
   [self _finalize];
#endif
   [super dealloc];
}

Caveat

-finalize is single-threaded, just like -init and -dealloc when called during release. When you -performFinalize it can only be guaranteed that no other thread will be executing -finalize (ever). But it is not guaranteed that no other thread is accessing the object.

Tags: runtime 8.0.0