Page History

If a program relies A program may leak resources when it elies on finalize() to release system resources , or if when there is confusion over which part of the program is responsible for releasing system resources, then there exists a possibility of a potential resource leak. In a busy system, there might be a time gap the delay before the finalize() method is called for an object . An attacker might exploit this vulnerability to provides a window of vulnerability during which an attacker could induce a denial-of-service attack. The See the guideline OBJ08-J. Avoid using finalizers has more information on the demerits of using for additional reasons to avoid the use of finalizers.

The Java garbage collector is called to free up unreferenced but as-yet unreleased memory. However, if the program relies on the Java garbage collector cannot free non-memory resources like such as file descriptors and database connections, unreleased resources might lead the program to prematurely exhaust its pool of . Consequently, programs that fail to release such non-memory resources can prematurely exhaust their pool of such resources. In addition, if the program uses resources like Lock or Semaphore, programs can experience resource starvation while waiting for finalize() to release the resources may result in resource starvation. Caching of object references in the output stream also implies that the 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 not be garbage collected unless the streams are until after the output stream is closed. Consequently, output streams should be closed promptly after use.

Also note that on the Windows platform, attempts to delete open files fail silently. See guideline FIO07-J. Do not create temporary files in shared directories for more information.

There is a similar guideline for releasing concurrency locks: guideline See also the related locking guideline LCK08-J. Ensure actively held locks are released on exceptional conditions.

...

The problem of resource pool exhaustion is aggravated in the case of database connections. Traditionally, database servers have allowed a fixed number of connections, depending on configuration and licensing. Failing Failure to release database connections can result results in rapid exhaustion of available connections. This noncompliant code example does not fails to close the connection if when an error occurs while executing during execution of the SQL statement or while during processing of the results.

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) { /* forward to handler */ }
}

Noncompliant Code Example

While being slightly better than the previous This noncompliant code example , this code is also noncompliant. Both attempts to address the above problem by adding clean-up code in a finally block. However, either or both of rs and stmt might could be null and , in which case the clean-up code in the finally block may would result in a NullPointerException.

...

In this noncompliant code example, the call to rs.close() might itself result in a SQLException, and so as a result of which stmt.close() will would 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) { 
  // forward to handler 
} finally {
  if(rs != null) {
    rs.close();
  }
 
  if(stmt != null) {
    stmt.close();
  }
}

...

This noncompliant code example opens a file , and uses it, but does not 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, if a the FileInputStream object is instantiated, it will be closed as required (if it was created in the first place).

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) { 
  // forward to handler 
} finally {
  if(stream != null) { 
    stream.close();
  } 
}

...

Acquiring non-memory system resources and not releasing failing to release them explicitly may can result in resource exhaustion.

Automated Detection

Although sound automated detection of this vulnerability is not feasible in the general case, many interesting cases can be soundly detected.
The Coverity Prevent Version 5.0 RESOURCE_LEAK checker can detect the instances where there is leak of a socket resource or leak of a stream representing a file or other system resources.

...