Page History

...

• 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 . The Java Language Specification fails to define this behavior, leaving it to the individual implementations.

...

• Wiki Markup

  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. See the JavaOne presentation by Hans J. Boehm \[[Boehm 2005|AA. Bibliography#Boehm 05]\] for additional information.

...

Superclasses that use finalizers impose additional constraints on their extending classes. Consider an example from JDK 1.5 and earlier. The following noncompliant code example allocates a 16 MB buffer used to back a Swing JFrame object. Although none of the JFrame APIs have a lack finalize() method methods, JFrame extends AWT.Frame, which does have a finalize() method. When a MyFrame object becomes unreachable, the garbage collector cannot reclaim the storage for the byte buffer because code in the inherited finalize() method might refer to it. Consequently, the byte buffer must persist at least until the inherited finalize() method for class MyFrame completes its execution and cannot be reclaimed until the following garbage-collection cycle.

...

The class SubClass overrides the protected finalize() method and performs cleanup activities. Subsequently, it calls super.finalize() to make sure its superclass is also finalized. The unsuspecting BaseClass calls the doLogic() method, which happens to be overridden in the SubClass. This resurrects a reference to SubClass such that it is prevented not only prevents it from being garbage-collected but also prevents it from using calling its finalizer to close new resources that may have been allocated by the called method. As detailed in rule MET05-J. Ensure that constructors do not call overridable methods, if the subclass's finalizer has terminated key resources, invoking its methods from the superclass might lead one to observe the result in the observation of object in an inconsistent state. In some cases, this can result in NullPointerException.

...

Joshua Bloch \[[Bloch 2008|AA. Bibliography#Bloch 08]\] suggests implementing a {{stop()}} method explicitly such that it leaves the class in an unusable state beyond its lifetime. A {{private}} field within the class can signal whether the class is unusable. All the class methods must check this field prior to operating on the class. This is akin to the ["Initializedinitialized Flagflag" - compliant solution|OBJ11-J. Be wary of letting constructors throw exceptions#OBJ04-EX1] discussed in discussed in rule [OBJ11-J. PreventBe wary accessof toletting partiallyconstructors initializedthrow objectsexceptions#OBJ04-EX1]. As always, a good place to call the termination logic is in the {{finally}} block.

...

protected void finalize() throws Throwable {
  try {
    //...
  }
  finally {
    super.finalize();
  }
}

...

...