Yo! Avoid finalizers.

One of the oldie but goodie java books is "Effective Java" by Joshua Block, If you're a java developer and haven't read it yet, then it's time my boy. Each chapter in the book consists of several “items” presented in the form of a short, standalone essay that provides specific advice, insight into Java platform subtleties, and outstanding code examples. The comprehensive descriptions and explanations for each item illuminate what to do, what not to do, and why.

On item 7, Josh wrote:

Finalizers are unpredictable, often dangerous, and generally unnecessary.

The garbage collector invokes object finalizer methods after it determines that the object is unreachable but before it reclaims the object's storage. Execution of the finalizer provides an opportunity to release resources such as open streams, files, and network connections that might not otherwise be released automatically through the normal action of the garbage collector.

Why you should avoid them

• There is no fixed time at which finalizers must be executed because time of execution depends on the Java Virtual Machine (JVM). The only guarantee is that any finalizer method that executes will do so sometime after the associated object has become unreachable (detected during the first cycle of garbage collection) and sometime before the garbage collector reclaims the associated object's storage (during the garbage collector's second cycle). Execution of an object's finalizer may be delayed for an arbitrarily long time after the object becomes unreachable. Consequently, invoking time-critical functionality such as closing file handles in an object's finalize() method is problematic.

• The JVM may terminate without invoking the finalizer on some or all unreachable objects. Consequently, attempts to update critical persistent state from finalizer methods can fail without warning. Similarly, Java lacks any guarantee that finalizers will execute on process termination. Methods such as System.gc(), System.runFinalization(), System.runFinalizersOnExit(), and Runtime.runFinalizersOnExit() either lack such guarantees or have been deprecated because of lack of safety and potential for deadlock.

• Uncaught exceptions thrown during finalization are ignored. When an exception thrown in a finalizer propagates beyond the finalize() method, the process itself immediately stops and consequently fails to accomplish its sole purpose. This termination of the finalization process may or may not prevent all subsequent finalization from executing. The JLS fails to define this behavior, leaving it to the individual implementations.

• Coding errors that result in memory leaks can cause objects to incorrectly remain reachable; consequently, their finalizers are never invoked.

• A programmer can unintentionally resurrect an object's reference in the finalize() method. When this occurs, the garbage collector must determine yet again whether the object is free to be deallocated. Further, because the finalize() method has executed once, the garbage collector cannot invoke it a second time.

• It is a common myth that finalizers aid garbage collection. On the contrary, they increase garbage-collection time and introduce space overheads. Finalizers interfere with the operation of modern generational garbage collectors by extending the lifetimes of many objects. Incorrectly programmed finalizers could also attempt to finalize reachable objects, which is always counterproductive and can violate program invariants.

• Use of finalizers can introduce synchronization issues even when the remainder of the program is single-threaded. The finalize() methods are invoked by the garbage collector from one or more threads of its choice, these threads are typically distinct from the main() thread, although this property is not guaranteed. When a finalizer is necessary, any required cleanup data structures must be protected from concurrent access.

• Use of locks or other synchronization-based mechanisms within a finalizer can cause deadlock or starvation. This possibility arises because neither the invocation order nor the specific executing thread or threads for finalizers can be guaranteed or controlled.

With that been said, you can continue using finalizers on your own risk!

• http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7