Page History

Before the garbage collector acts on an object to reclaim it, the object's finalizer is executed. This is required to ensure that resources such as open streams, files and network connections get freed since released as resource management does not happen automatically while reclaiming memory. In Java, the finalize() method of java.lang.Object is used to perform this activity.

...

• There is no fixed time for finalizers to get executed, which again ; this detail is JVM dependent: The only thing that is guaranteed is that if at all a finalizer gets executed, it will be before the garbage collector's second cycle. An object may become unreachable and yet its finalizer may not execute for an arbitrarily long time. Nothing of time-critical nature should be run in the finalize method, for . For instance, closing file handles is not recommended.

...

• Wiki Markup
  According to the Java Language Specification: \[[JLS 05|AA. Java References#JLS 05]\] Section 12.6.2 "Finalizer Invocations are Not Ordered":

  Wiki Markup
  The Java programming language imposes no ordering on finalize method calls. Finalizers \[of different objects\] may be called in any order, or even concurrently.

  This can be a problem as slow running finalizers tend to block others in the queue.

...

• A possibility exists such that the programmer unintentionally resurrects the references object's reference in the finalize method. While the garbage collector must determine yet again whether the object is free to be deallocated, the finalize method is not invoked again.

• A superclass can use finalizers and pass some additional overhead to extending classes. An example from JDK 1.5 and earlier demonstrates this. The code snippet shown below allocates a 16 MB buffer for backing a Swing Jframe. None of the JFrame APIs have a finalize method, however, JFrame extends AWT Frame which has a finalize method. The byte buffer continues to persist until the finalize method gets called and lasts for at least two garbage collection cycles.

...

• It is also imprudent to use finalizers for reclaiming scarce resources by inviting enforcing garbage collection. Garbage collection usually depends on memory related traits and not on the scarcity of a particular resource. As a result, if memory is available aplenty, there is no reason for the scarce resource to not get exhausted despite the use of a finalizer. See FIO32-J. Ensure all resources are properly closed when they are no longer needed and CON02-J. Facilitate thread reuse by using Thread Pools for more details on handling resources correctly.

...

• Wiki Markup

  It is not advisable to use any lock or sharing based mechanisms within a finalizer due to the inherent dangers of deadlock and starvation. On the other hand, it is also easy to miss that there can be synchronization issues with the use of finalizers even if the source program is single-threaded. This is because the {{finalize()}} methods are called from their own threads. If at aall finalizer is inevitablenecessary, the cleanup data structure should be protected from concurrent access (See \[[Boehm 05|AA. Java References#Boehm 05]\]).

...

The System.runFinalizersOnExit() method has been is used in this noncompliant example to simulate a garbage collection run (note that this method is deprecated due to because of thread-safety issues).

According to the Java API \[[API 06|AA. Java References#API 06]\] class {{System}}, {{runFinalizersOnExit()}} method documentation:

Enable or disable finalization on exit; doing so specifies that the finalizers of all objects that have finalizers that have not yet been automatically invoked are to be run before the Java runtime exits. By default, finalization on exit is disabled.

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 not only prevented from getting garbage collected but also cannot further use its finalizer anymore to close new resources that may have been allocated by the called method. As detailed in MET32-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 object in an inconsistent state and in the worst case . In some cases this can result in the infamous NullPointerException.

class BaseClass {
  protected void finalize() throws Throwable {
    System.out.println("Superclass finalize!");
    doLogic();
  }

  public void doLogic() throws Throwable{
    System.out.println("This is super-class!");
  }
}

class SubClass extends BaseClass {
  private Date d; // mutable instance field

  protected SubClass() {
    d = new Date();
  }

  protected void finalize() throws Throwable {
    System.out.println("Subclass finalize!");
    try {
      //  cleanup resources 
      d = null;				
    } finally {
      super.finalize();  // call BaseClass' finalizer
    }
  }
	
  public void doLogic() throws Throwable{
    /* any resource allocations made here will persist */

    // inconsistent object state
    System.out.println("This is sub-class! The date object is: " + d);  // 'd' is already null
  }
}

public class BadUse {
  public static void main(String[] args) {
    try {
      BaseClass bc = new SubClass();
      System.runFinalizersOnExit(true); // artificially simulate finalization (do not do this)
      System.runFinalizersOnExit(true); 
    } catch (Throwable t) { /* handle error */ }  		
  }
}

A As expected, this code outputs:

...

OBJ02-EX1: Sometimes it is necessary to use finalizers especially while working with native objects/code. This is because the garbage collector cannot re-claim memory from used by code written in another language. Also, the lifetime of the objects object is often unknown. Again, the native process must not perform any critical jobs that require immediate resource deallocation.

In such cases, finalize should be used correctly. Any subclass that overrides finalize() must explicitly invoke the method for its superclass as well. There is no automatic chaining with finalize. The correct way to handle this is shown nextbelow.

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

Alternatively, a more expensive solution is to declare an anonymous class so that the {{finalize}} method is guaranteed to run for the superclass. This solution is applicable to {{public}} non-final classes. "The finalizer guardian object forces {{super.finalize}} to be called if a subclass overrides {{finalize()}} and does not explicitly call {{super.finalize}}". \[[JLS 05|AA. Java References#JLS 05]\] Section 12.6.1: Implementing Finalization.

...

The ordering problem can be dangerous while when dealing with native code. For example, if object A references object B (either directly or reflexivelyreflectively) and the latter gets finalized first, A's finalizer may end up dereferencing dangling native pointers. To impose an explicit ordering on finalizers, make sure that B is reachable before A's finalizer has concluded. This can be done achieved by adding a reference to B in some global state variable and removing it as soon as A's finalizer gets executed. An alternative is to use the java.lang.ref references.

If a superclass defines a finalize method, make sure to decouple the objects that can be immediately garbage collected from those that depend on the finalizer. In the MyFrame example, the following code will ensure ensures that the buffer doesn't persist longer than expected.

...

Compliant Solution (finalization)

Joshua Bloch \[[Bloch 08|AA. Java References#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 *EX1* discussed in [OBJ32-J. Do not allow partially initialized objects to be accessed]. As always, a good place to call the termination logic is in the {{finally}} block.

Risk Assessment

Finalizers can have unexpected behaviorThe improper use of finalizers can result in resurrection of garbage-collection ready objects and result in denial of service vulnerabilities.

...