Garbage collection and memory management in Java applications

As a modern language, Java has an automatic memory management mechanism called garbage collection, which makes it much easier for you to manage objects created in the application code. When an object is created by new keyword, it is placed into the Java heap of the Java Virtual Machine (JVM). The JVM has a garbage collector, and when this object is no longer needed by any code, the garbage collector removes it from the Java heap. Listing 1 is an example of a method defined in a Java class

public void aMethod() {
String example = new String("My Example"); // String is a Java class
}

In above example, a new String object is allocated in the Java heap. In Java , you don't need to write code to explicitly delete the object from the heap after you're done with it. When the method is called and returned, the only reference to this String object, s, is set to null and removed from the thread stack. The JVM garbage collector detects that the number of references to this String object is 0, indicating no code may access or use the object any longer. When the garbage collector has an opportunity to run, it treats this String object as garbage, removes it from the Java heap, and frees the memory allocated for it.

Java memory leaks

If a program holds a reference to a heap chunk that is not used during the rest of its life, it is considered a memory leak because the memory could have been freed and reused. GC won't reclaim it due to the reference being held by the program. A Java program could run out of memory due to such leaks. Java memory leaks are mostly a result of non-obvious programming errors.

Finding Reason for memory leaks
Usually, solving a memory leak problem is a two-step process:identifying which Java classes caused the memory leak, and then determining where in the application leak occurred. The goal of the first step is easy to achieve with the tools

The second step is more challenging, because tracking the relevant information in a profiling tool slows down performance. The profiler discussed in this article doesnot provide the detailed information needed to track down the source of memory leaks inthe code, partly because of performance considerations. Some tools may be configured to collect such information with significant adverse impact on performance, such as Hprof and other third party tools.Given the scale of J2EE applications and the J2EE environment associated with them, performance concerns often prevent developers from tracking sufficient information using those tools.

To simplify the discussion of resolving the difficulty in the second step in this article, memory leaks are divided into two types.

1. Rarely used object leak
2. Frequently used object leak

Preventing memory leaks

You can prevent memory leaks by watching for some common problems. Collection classes,
such as hashtables and vectors, are common places to find the cause of a memory leak.
This is particularly true if the class has been declared static and exists for the life of the application.

Another common problem occurs when you registera class as an event listener without bothering to unregister when the class is no longer needed. Also, many times member variables of a class that point to other classes simply needto be set to null at the appropriate time.