Resource Leaks

Similar to memory leak, a resource leak depletes system resources, which degrades performance and can lead to a failure.

Every object uses system resources, such as memory. An appropriate way is needed to to give resources back to the system when they’re no longer needed because “resource leaks” might occur and this would prevent them from being reused by recent program or other programs.. Programs that obtain certain types of resources must return them to the system explicitly to avoid so-called resource leaks. In programming languages such ac C++, the most common kind of resource leak is a memory leak. 

Java uses an automatic garbage collection of memory no longer used by programs, thus avoiding most memory leaks. When there are no more references to an object, the object is eligible to be collected. So, memory leaks that are common in other languages like C and C++ (because memory is not automatically reclaimed in those languages) are less likely in Java, but some can still happen in subtle ways. However other types of resource leaks can occur. For example: files, database connection and network connections that are not closed properly after they're no longer needed might not be available for use in other program.  

The garbage collector calls the finalize method in order to perform termination housekeeping on an object just before the garbage collector reclaims the object’s memory. Method finalize has return type void and does not take parameters. A problem with method finalize is that the garbage collector is not guaranteed to execute at a specified time. In fact, the garbage collector may never execute before a program terminates. Thus, it’s unclear whether, or when, method finalize will be called. For this reason, most programmers should avoid method finalize.  

A class that uses system resources, such as files on disk, should provide a method that programmers can call to release resources when they’re no longer needed in a program. Many Java API classes provide close or dispose methods for this purpose. For example, class Scanner has a close method. 

A subtle issue is that Java does not entirely eliminate memory leaks. Java will not garbage collect an object until there are no remaining references to it. Thus, if you erroneously keep references to unwanted objects, memory leaks can occur. To help avoid this problem, set reference-type variables to null when they’re no longer needed.  

The finally block is optional. If it is used, it is placed after the last catch block. If there are no catch blocks, the finally block follows the try block. The finally block will execute whether or not an exception is thrown in the corresponding try block. The finally block also will execute if a try block exits by using a return, break or continue statement or simply by reaching its closing right brace. The finally block will not execute if the application exits early from a try block by calling method System.exit.  Because a finally block almost always executes, it typically contains resource-release code. 

Let's suppose a resource is allocated in a try block; if no exception is occurring, the catch blocks are skipped and control proceeds to the finally block, which frees the resource. It then proceeds to the first statement after the finally block. If an exception occurs in the try block, then the try block will terminate. If the program catches the exception in one of the corresponding catch blocks, it will perform the exception, then the finally block will release the resource and control proceeds to the first statement after the finally block. If the program doesn’t catch the exception, the finally block still releases the resource and an attempt is made to catch the exception in a calling method. The finally block is an ideal place to release resources acquired in a try block (such as opened files), which helps eliminate resource leaks. Always release a resource explicitly and at the earliest possible moment at which it’s no longer needed. This makes resources available for reuse as early as possible, thus improving resource utilization.

If an exception that occurs in a try block cannot be caught by one of that try block’s catch handlers, the program skips the rest of the try block and control proceeds to the finally block. Then the program passes the exception to the next outer try block, normally in the calling method, where an associated catch block might catch it. This process can occur through many levels of try blocks. Also, the exception could go uncaught. If a catch block throws an exception, the finally block still executes. Then the exception is passed to the next outer try block—again, normally in the calling method.