Finding Memory Leaks using JVisualVM.

I am using JVisualVm for detecting any memory leaks in one of the modules.

The following are the steps i used to detect memory leaks. Please correct me if i am not doing it correct.

Step 1 : Initialize Weblogic Server run the Web application
Step 2: Initialize JVisualVM and start Memory Profiliing.
Step 3 : Perform some operations in the related module.
Step 4 : Now take a snapshot of the Memory.
Step 5 : Move on to another module which has completly different Packages or referred classes
Step 6 : Perform some operation and repeat Step 4.
Step 7 : Compare both the snapshots and see if any objects related to first Modules are remaining in the second Snapshot.
Step 8 : If there are no objects / their allocations then there is no memory leak.

Are these steps correct ?

Now if i found a memory leak then how to trace which method in that class or which object in that class is creating the issue?

I'd start with enabling gc logs , then use gcviewer to try and understand what your gc activity is like and is it getting worse with time. The next tool I use is Eclipse MAT and its reports eg top consumer, memory leak suspects, after that I usually know if I have an issue and then employ Visual VM if I need to drill down.

I would say that you need to stress the application. Use some automation load test tool for that. The concepts which will drive your steps that you have to configure is to start simple. Try the most used use cases but reaching the limit of users that the hardware allows you. Then you have to figure out what it the bottleneck. As you are seeking for a memory leaking and it is the case, you take a heap dump from the process during the load test and see what is using most of memory. In the MAT (eclipse tool for java memory analyzer) have some reports for that. You need to understand if it make sense holding those objects and take decisions how to deal with them to scale. This following book gives a lot of great ideas around this subject -> http://www.amazon.com/Pro-Java-Performance-Management-Optimization/dp/1590596102 .

Chris Hurst wrote:I'd start with enabling gc logs , then use gcviewer to try and understand what your gc activity is like and is it getting worse with time. The next tool I use is Eclipse MAT and its reports eg top consumer, memory leak suspects, after that I usually know if I have an issue and then employ Visual VM if I need to drill down.

Yeah, GC is a good tool too. Check the time spend on GC is less than 10% of time , for example.

Memory analysis tools won't tell you when and where an object was created. It will only tell you which objects are in heap. TO find the when and where, you will have to dig into the code and/or add logging yourself

Think of looking at a heap dump like being a detective at a crime scene. Let's say a guy is shot, and you are the detective. By looking at the crime scene, you can see exactly how the guy died, but you can't tell who did it. To find out who did it, you need to collect other pieces of information and put them together to find exactly what happened. Now, it would be very convenient if there was a camera recording the crime when it happened. You can go to the recording and see what happened. Boom. you have your culprit. But, when you don;t have a camera recording, that's whn you have to use your detective skills. You have to talk to people, and try to make a picture of what happened before the shooting.

ANalyzing a memory leak is just like that. By looking a heap dump, you can tell what exactly caused the heap to fill up. It won;t tell you how it happneed. Now, if you had detailed enough logs, then that would be like a camera pointed at the crime scene. You could go through the logs and find exactly where those objects that filled up the heap got created. Not as easy as watching a recording, but doable. If you don't have logs, then you need to piece together other information to find what happened. You should look at the pattern used to reproduce the problem, and look at the source code to find where the object is being created.

Fortunately, for us software engineers, finding how to reproduce a problem is like going back in time. If you can reproduce the problem consistently, and you have a good idea of which object is causing the problem, you can add logging and the reproduce the problem again. That's like going back in time, putting a camera on the crime scene and letting the crime happen.