If the program relies on finalize() to release system resources, or there is confusion over which part of the program is responsible for releasing system resources, then there exists a possibility for 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 denial-of Service -service attack. Rule OBJ02-J has more information on the usage of finalizers.
If there is unreleased memory, eventually the Java garbage collector will be called to free memory; however, if the program relies on non-memory nonmemory resources like file descriptors descriptors and database connections, unreleased resources might lead the program to prematurely exhaust it's 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 resource starvation.
...
This problem is aggravated in the case of database connections. Traditionally, database servers allow a fixed number of connections, which may be dependant dependent on configuration or licensing issues. Not releasing such connections could lead to rapid exhaustion of available connections.
...
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. The use of a A finally block can be used to ensure that close statements are eventually called.
...