Is it possible to check the memory leak without going into the code. I have the application with me and I want to check whether there is memory leak or not.
In my present organisation, I check the cpu usage before and after running the application as well as the cpu usage of the process of the application. But I don't think this is the correct method.
Please advise me in this regard.
I think you need a memory profiler to do this.
You can find a list of profilers here
Open Source Profilers for Java
also read this article on
If you run your Java application with the following flag:
-Dcom.sun.management.jmxremote
You will be able to connect to it with jconsole. jconsole is a tool that comes with Java and resides in the bin directory where the java program is found. You can run it and observe memory usage over time (it's not great, but can help in spotting leaks). On very recent versions of Java (late builds of 1.6) you can also run jvisualvm which is similar to jconsole but will also tell you how many of each class is instantiated, which is more useful.
You are right that watching only the memory is not really easy with Java as it involves a garbage collector and would have a kind of saw pattern. Nevertheless could the recording of memory consumption of the whole application over a long time be useful.
If you have some automatic mean to "remote control" the application (Like SendKeys under windows) you could make nice time memory consumption diagrams. Use your favorite table calculation program to draw a linear interpolation of the data. If this shows up a regular upwards trend, you could say that there is a leak. Only do this in a state where the application is not supposed to grow in memory, which can also be done with healthy human thinking about what information an application would need to store to display/process the data.
Of course other tools are needed to drill down to threads or classes (see other responses).
Analysing the memory consumption of a Java application should not be done by using OS tooling, IMHO. A running JVM will allocate an amount of memory and is unlikely to release it, even if it is not actually needed by the JVM at a given point in time. An OS tool will only report the amount of memory that was allocated by the JVM, not the amount of memory that is actually committed within the JVM.
The tooling provided with the JDK (jstat, jconsole, jvisualvm) is much more reliable. When interpreting memory usage, the most important thing is the size of the actual heap. A Java application will typically display a sawtooth pattern. The amount of heap in use will rise gradually over time, and drop off sharply when GC frees heap space by removing all the objects that are no longer needed.
A definite warning signal is a sawtooth that is slowly ascending: the sharp drop caused by the GC is ending a little higher every time. If the application runs for a long time (typically for a server application), this will most probably cause an OutOfMemory error in the long run.
Another thing to wach for is a sawtooth where the 'teeth' are getting sharper and higher. This also indicates that the application will need more and more memory over time.
If you want to analyse the root casue of a perceived problem you need to analyse the number of objects created and have a look at how long they live. This is not trivial stuff.