Page History

If a program relies on finalize() to release system resources, or if there is confusion over which part of the program is responsible for releasing system resources, then there exists a possibility for of a potential resource leak. In a busy system, there might be a time gap before the finalize() method is called for an object. An attacker might exploit this vulnerability to induce a denial-of-service attack. The recommendation OBJ02-J. Avoid using finalizers has more information on the demerits of using finalizers.

The Java garbage collector is called to free up unreleased memory. However, if the program relies on nonmemory non-memory resources like file descriptors and database connections, unreleased resources might lead the program to prematurely exhaust its pool of resources. In addition, if the program uses resources like Lock or Semaphore, waiting for finalize() to release the resources may lead to result in resource starvation. Caching of object references in the output stream also implies that the objects will not be garbage collected unless the streams are closed promptly after use.

On Also note that on the Windows platform, attempts to delete open files fail silently.

Noncompliant Code Example

This The problem of resource pool exhaustion is aggravated in the case of database connections. Traditionally, database servers allow a fixed number of connections, which may be dependent on configuration or licensing issues. Not releasing such connections could lead to . Failing to release database connections can result in rapid exhaustion of available connections.

In this noncompliant code example, if an error occurs while executing the statement or while processing the results of the statement, the connection is not closed.

public void getResults(String sqlQuery) {
  try {
    Connection conn = getConnection();
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
    stmt.close();
  } catch (SQLException e) { }
}

In the case above, if an error occurs while executing the statement or while processing the results of the statement, the connection is not closed. A finally block can be used to ensure that the close statements are eventually called.

Noncompliant Code Example

However, while While being slightly better than the previous example, this code is also noncompliant. Both rs and stmt might be null and the clean-up code in the finally block may result in a NullPointerException.

Statement stmt = null;
ResultSet rs = null
Connection conn = getConnection(0;
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch(SQLException e) { }
  finally {
    rs.close();
    stmt.close();
}
}

Noncompliant Code Example

Again, while being still better, the this code snippet is still noncompliant. This is because rs.close() might itself result in a SQLException, and so stmt.close() will never be called.

Statement stmt = null;
ResultSet rs = null;
Connection conn = getConnection();
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch(SQLException e) { }
  finally {
    if(rs != null) {
      rs.close();
    }
    if(stmt != null) {
      stmt.close();
    }
}
}

Compliant Solution

This compliant solution shows how to ensure that resources have been released.

Statement stmt = null;
ResultSet rs = null;
Connection conn = getConnection();
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch(SQLException e) { }
  finally {
     try {
       if(rs != null) {
        rs.close();
       }
     } finally ({
        try {
          if(stmt != null) {
            stmt.close();
          }
        }
        finally {
           conn.close();
        }
      }
}

Noncompliant Code Example

The worst form of noncompliance is not calling methods to release the resource at all. If files are opened, they must be explicitly closed when their work is doneThis noncompliant code example opens a file, uses it, but does not explicitly close the 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;
}

Compliant Code Example

This compliant code example would release releases all acquired resources, regardless of any exceptions which that might occur. Hence, in the compliant code belowIn this compliant solution, even though bufRead might result in an exception, if a FileInputStream object was is instantiated, it will be closed as required.

FileInputStream stream = null;
BufferedReader bufRead = null;
String line;
try {
  stream = new FileInputStream(fileName);
  bufRead = new BufferedReader(new InputStreamReader(stream));
  while((line = bufRead.readLine()) != null) {
	    sendLine(line);
  }
} catch (IOException e) { }
finally {
  if(stream != finallynull) { 
    stream.close();
  } 
}

Risk Assessment

Acquiring nonmemory non-memory system resources and not releasing them explicitly might lead to may result in resource exhaustion.

...