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.

A sufficient number of problems are associated with finalizers to restrict their use to exceptional conditions:

Object finalizers have also been deprecated since Java 9. See MET02-J. Do not use deprecated or obsolete classes or methods for more information.

Because of these problems, finalizers must not be used in new classes.

Noncompliant Code Example (Superclass's finalizer)

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 the JFrame APIs lack finalize() 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.

class MyFrame extends JFrame {
  private byte[] buffer = new byte[16 * 1024 * 1024];
  // Persists for at least two GC cycles

Compliant Solution (Superclass's finalizer)

When a superclass defines a finalize() method, make sure to decouple the objects that can be immediately garbage collected from those that must depend on the finalizer. This compliant solution ensures that the buffer can be reclaimed as soon as the object becomes unreachable.

class MyFrame {
  private JFrame frame;
  private byte[] buffer = new byte[16 * 1024 * 1024]; // Now decoupled

Noncompliant Code Example (System.runFinalizersOnExit())

This noncompliant code example uses the System.runFinalizersOnExit() method to simulate a garbage-collection run. Note that this method is deprecated because of thread-safety issues.

According to the Java API [API 2014] 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 that not only prevents it from being garbage-collected but also prevents it from calling its finalizer to close new resources that may have been allocated by the called method. As detailed in 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 result in the observation of an object in an inconsistent state. In some cases, this can result in NullPointerException.

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

  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's finalizer

  public void doLogic() throws Throwable {
    // Any resource allocations made here will persist

    // Inconsistent object state
        "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();
      // Artificially simulate finalization (do not do this)
    } catch (Throwable t) {
      // Handle error

This code outputs:

Subclass finalize!
Superclass finalize!
This is sub-class! The date object is: null

Compliant Solution

Joshua Bloch [Bloch 2008] 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 "initialized flag"–compliant solution discussed in OBJ11-J. Be wary of letting constructors throw exceptions. As always, a good place to call the termination logic is in the finally block.


MET12-J-EX0: Finalizers may be used when working with native code because the garbage collector cannot reclaim memory used by code written in another language and because the lifetime of the object is often unknown. Again, the native process must not perform any critical jobs that require immediate resource deallocation.

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 it is as follows:

protected void finalize() throws Throwable {
  try {
  } finally {

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 nonfinal classes. "The finalizer guardian forces super.finalize to be called if a subclass overrides finalize() and does not explicitly call super.finalize" [JLS 2015].

public class Foo {
  // The finalizeGuardian object finalizes the outer Foo object
  private final Object finalizerGuardian = new Object() {
    protected void finalize() throws Throwable {
      // Finalize outer Foo object

The ordering problem can be dangerous when dealing with native code. For example, if object A references object B (either directly or reflectively) 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 remains reachable until A's finalizer has concluded. This can be achieved by adding a reference to B in some global state variable and removing it when A's finalizer executes. An alternative is to use the java.lang.ref references.

MET12-J-EX1: A class may use an empty final finalizer to prevent a finalizer attack, as specified in OBJ11-J. Be wary of letting constructors throw exceptions.

Risk Assessment

Improper use of finalizers can result in resurrection of garbage-collection-ready objects and result in denial-of-service vulnerabilities.




Remediation Cost









Automated Detection



Empty finalizer should be deleted
Explicit invocation of finalizer
Finalizer nulls fields
Finalizer nulls fields
Finalizer does not call superclass finalizer
Finalizer nullifies superclass finalizer
Finalizer should be protected, not public
Finalizer does nothing but call superclass finalizer



Parasoft Jtest
The Object.finalize() method should not be overriden
The Object.finalize() method should not be called
"Object.finalize()" should remain protected (versus public) when overriding
"runFinalizersOnExit" should not be called
"super.finalize()" should be called at the end of "Object.finalize()" implementations

Related Vulnerabilities

AXIS2-4163 describes a vulnerability in the finalize() method in the Axis web services framework. The finalizer incorrectly calls super.finalize() before doing its own cleanup, leading to errors in GlassFish when the garbage collector runs.

Related Guidelines


CWE-586, Explicit call to Finalize()

CWE-583, finalize() Method Declared Public

CWE-568, finalize() Method without super.finalize()


[API 2014]

Class System

[Bloch 2008]

Item 7, "Avoid Finalizers"

[Boehm 2005]

[Coomes 2007]

"'Sneaky' Memory Retention"

[Darwin 2004]

Section 9.5, "The Finalize Method"

[Flanagan 2005]

Section 3.3, "Destroying and Finalizing Objects"

[JLS 2015]

§12.6, "Finalization of Class Instances"