The garbage collector invokes object finalizer methods after it has determined 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, whose resources may not otherwise be released automatically through the normal action of the garbage collector. In Java, the finalize() method of java.lang.Object is used for this purpose.
There are a number of caveats associated with the use of finalizers:
- There is no fixed time at which finalizers must be executed; this detail depends on the 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, avoid implementing time-critical functionality in an object's
finalize()method. For instance, closing file handles in a finalizer is not recommended.
- 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 provides no guarantee that finalizers will execute on process termination. Methods such as
System.gc(),System.runFinalization(),System.runFinalizersOnExit()andRuntime.runFinalizersOnExit()either lack such guarantees or have been deprecated because of lack of safety and potential for deadlock.
According to the Java Language Specification [[JLS 2005]] Section 12.6.2 "Finalizer Invocations are Not Ordered"
One consequence is that slow-running finalizers can delay execution of other finalizers in the queue. Further, the lack of guaranteed ordering can lead to substantial difficulty in maintaining desired program invariants.The Java programming language imposes no ordering on
finalizemethod calls. Finalizers [of different objects] may be called in any order, or even concurrently.
- Uncaught exceptions thrown during finalization are ignored. When an exception is thrown in a finalizer, the process itself immediately stops, and consequently fails to accomplish its sole purpose.
- Coding errors that result in memory leaks imply that objects incorrectly remain reachable; thus 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 thefinalize()method has executed once, the garbage collector cannot invoke it a second time.
- Superclasses that use finalizers impose additional constraints on their extending classes. Consider an example from JDK 1.5 and earlier. The code snippet below allocates a 16 MB buffer used to back a Swing
Jframeobject. Although none of theJFrameAPIs have afinalize()method,JFrameextendsAWT.Framewhich does have afinalize()method. When aMyFrameobject becomes unreachable, the garbage collector cannot reclaim the storage for the byte buffer because code in the inheritedfinalize()method might refer to it. Consequently, the byte buffer must persist at least until the inheritedfinalize()method for classMyFramecompletes 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
}
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. In the MyFrame example, the following code 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
}
- Avoid using finalizers to release scarce resources as a side-effect of garbage collection. Garbage collection usually depends on memory availability and usage rather than on the scarcity of some other particular resource. Consequently, when memory is readily available, a scarce resource may be exhausted in spite of the presence of a finalizer that could release the scarce resource if it were executed. See guidelines FIO06-J. Ensure all resources are properly closed when they are no longer needed and TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts for more details on handling scarce resources correctly.
- 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 themain()thread, although this property is not guaranteed. When a finalizer is necessary, any required cleanup data structures should be protected from concurrent access. See [[Boehm 2005]] for additional information.
- Use of locks or other synchronization-based mechanisms within a finalizer can cause deadlock or starvation. This possibility arises because both the invocation order and the executing thread or threads for finalizers cannot be guaranteed or controlled.
Noncompliant Code Example
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; see guideline MET15-J. Do not use deprecated or obsolete methods.
According to the Java API [[API 2006]] 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 being garbage collected but also from using its finalizer to close new resources that may have been allocated by the called method. As detailed in guideline MET04-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. 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's 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();
// Artificially simulate finalization (do not do this)
System.runFinalizersOnExit(true);
} catch (Throwable t) {
// Handle error
}
}
}
This code outputs:
Subclass finalize! Superclass finalize! This is sub-class! The date object is: null
Compliant Solution
This compliant solution eliminates the call to the overridable doLogic() method from within the finalize() method.
class BaseClass {
protected void finalize() throws Throwable {
System.out.println("superclass finalize!");
// Eliminate the call to the overridden doLogic().
}
...
}
Compliant Solution (Finalization)
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 OBJ04-EX1 discussed in guideline [OBJ04-J. Do not allow access to partially initialized objects]. As always, a good place to call the termination logic is in the finally block.
Exceptions
OBJ02-EX1: Sometimes it is necessary to use finalizers especially when working with native code. This is because the garbage collector cannot re-claim memory used by code written in another language. Also, the lifetime of the object is often unknown. Again, the native process must not perform any critical jobs that require immediate resource deallocation.
In such cases, finalize() may be used. 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 below.
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 2005]]
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 is reachable before A's finalizer has concluded. This can be 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.
Risk Assessment
Improper use of finalizers can result in resurrection of garbage-collection ready objects and result in denial of service vulnerabilities.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
OBJ08-J |
medium |
probable |
medium |
P8 |
L2 |
Automated Detection
TODO
Related Vulnerabilities
Bibliography
[[API 2006]] finalize()
[[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 2005]] Section 12.6, Finalization of Class Instances
[[MITRE 2009]] CWE ID 586 "Explicit Call to Finalize()", CWE ID 583 "finalize() Method Declared Public", CWE ID 568 "finalize() Method Without super.finalize()"
OBJ07-J. Understand how a superclass can affect a subclass Object Orientation (OBJ) OBJ09-J. Immutable classes must prohibit extension