+1  A: 

I generally take a couple of heapdumps each few seconds apart just to see the pattern of what is being released and what might be sticking around.

Then I drill down into the objects that are suspicious and find what is holding the reference to them. Often it boils down to some resources not being closed properly, excessive use of session objects, static variables, leaks in some class loaders, inmemory cache or some object in a list that is still being referenced to.

It not always easy to go through though hundreds and thousands of objects and interpret what's going on. I have found this course on JavaPassion to be very helpful to a beginner.

Langali
+1  A: 

The best way to detect a memory leak in any application (Java or not) is to take periodic snapshots of memory, while the application is in use, followed by a close examination of the object count for the different types of objects managed by the application.

Most memory leaks can be traced to a group of objects that show the largest increase in memory consumption. Briefly stated, one should give priority to Δ MEM(objects) as opposed to Σ MEM(objects).

Once you have identified the set of objects responsible for the leak, you then need to pinpoint the source of the leak, via the object allocation trace.

For a quick introduction, on how to do this with Netbeans, you can take a look at one of the tutorials at Java Passion.

In Eclipse, you will find the MAT plugin's ability to depict the dominator tree to be very useful.

Finally, the following list of terms would be useful, since efficient analysis requires knowledge of these as pre-requisites:

Vineet Reynolds