Page History

The Java garbage collector is called to free unreferenced but as-yet unreleased memory. However, the Java garbage collector cannot free non-memory resources such as file descriptors and database connections. Consequently, programs that fail failing to release such non-memory resources can prematurely exhaust their pool of such resourceslead to resource exhaustion attacks. In addition, programs can experience resource starvation while waiting for finalize() to release resources such as Lock or Semaphore objects. This can occur because Java lacks any temporal guarantee of when finalize() methods will execute, other than "sometime before program termination." Finally, output streams may cache object references; such cached objects will are not be garbage collected until after the output stream is closed. Consequently, output streams should be closed promptly after use.

A program may leak resources when it relies on finalize() to release system resources or when there is confusion over which part of the program is responsible for releasing system resources. In a busy system, the delay before the finalize() method is called for an object provides a window of vulnerability during which an attacker could induce a denial-of-service attack. Consequently, resources other than raw memory must be explicitly freed in non-finalizer methods, because of the unsuitability of using finalizers. See the rule MET18-J. Do not use finalizers for additional reasons to avoid the use of finalizers.

Also note Note that on the Windows platform, attempts to delete open files fail silently. See rule FIO07-J. Remove temporary files before termination for more information.

See also the related locking rule LCK08-J. Ensure actively held locks are released on exceptional conditions.

Resources other than raw memory must be explicitly freed in non-finalizer methods, because of the unsuitability of using finalizers.

Noncompliant Code Example (File Handle)

This noncompliant code example opens a file and uses it, but fails to explicitly close the file handle.

public int processFile(String fileName) throws IOException, FileNotFoundException {
  FileInputStream stream = new FileInputStream(fileName);
  BufferedReader bufRead = new BufferedReader(new InputStreamReader(stream));
  String line;
  while ((line = bufRead.readLine()) != null) {
    sendLine(line);
  }
  return 1;
}

...

This compliant solution releases all acquired resources, regardless of any exceptions that might occur. Even though dereferencing bufRead might result in an exception, the FileInputStream object is closed as required (if it was created in the first place).

...

The try-with-resource construct will send sends any IOException to the catch clause, where it gets is forwarded to an exception handler. This includes exceptions generated during the allocation of resources (that is, the creation of the FileInputStream or BufferedReader. It also includes any IOException thrown during the while loop. Finally, it includes any IOException generated by closing bufRead or stream.

...

The problem of resource pool exhaustion is aggravated exacerbated in the case of database connections. Many database servers allow only a fixed number of connections, depending on configuration and licensing. Consequently, failure to release database connections can result in rapid exhaustion of available connections. This noncompliant code example fails to close the connection when an error occurs during execution of the SQL statement or during processing of the results.

...

In this noncompliant code example, the call to rs.close() could might throw an a SQLException; consequently. Consequently, stmt.close() would is never be called. This is a violation of ERR05-J. Do not let checked exceptions escape from a finally block.

...

The try-with-resource construct will send sends any SQLException to the catch clause, where it gets forwarded to an exception handler. This includes exceptions generated during the allocation of resources (that is, the creation of the Connection, Statement, or ResultSet). It also includes any SQLException thrown by processResults(). Finally, it includes any SQLException generated by closing rs, stmt, or conn.

...

...