We analyzed each of the profilers and described from ground up the process of downloading, installing and using VisualVM, YourKit and JProbe to try to solve a leaking Java application. While at it, we also measured their effect on application performance.

Each tool had its own “niche� in what you can find out about your application. But how about using them for systematically finding a memory leak? Well, it turns out that you can’t.

Do you have different experience with profilers? Read on and comment: http://www.plumbr.eu/blog/solving-outofmemoryerror-memory-profilers

While the author may be right that the tools don't automatically point out your memory leak in all situations, I've found that VisualVM (and I assume the other tools I have not used) can easily track things down as long as you actually know your application. The complaint that byte[] is the top class in the memory profile and hence won't find the leak is not true. If you apply a filter to the class list like com.yourcompany.* you will get only your application classes in the list. It's been my experience that there is usually one that will stand out and the sharp developer will ask themselves: "Why are there so many instances of class X?". Similar searches for com.databasevendor, org.apache, org.hibernate, org.springframework, and whatever web service stack your using at the time usually will point you right at your problem.

As JOhn mentioned I have extensively JMeter for tracking the memory leak.

I used it for the first time recently and it did two impressive things for me

* Fairly quickly opened 1.7g heap dump that jhat/jvisualvm were not ablo to load at all

* The very first report pointed out what the leak was.

 

It is true that MAT won't show the exact source of memory leak. However, knowing exactly what type of objects do leak together with the ability to navigate heap in a meaningful way do help greatly. 

I have the same experience with MAT and heap dump analysis.

One additional benefit of MAT is that it also works with IBM JDK's heap dump format (with their DTFJ extensions), whereas VisualVM doesn't.

-Laurent

I have also the same exp. with Jprobe , yourkit VM and JRockit mission control

The guy doesn't even know how to use the tools and then he complains they won't find his memory leaks.  Wow.  Yes, they won't just run some analysis and point to some code and say, "Here's your memory leak, dude!"  You have to actually know a little about the tool and how to use it.  I just recently went through this exercise with YourKit (which I had no prior experience with) and was able to track down my memory leak.  It took me about an hour but that's because I needed to learn how to get the tool to show me what I wanted.  I've done similar with jProfiler in the past.  If an hour is too much for you, then you're in the wrong line of work.

We used dynatrace as a plugin to our performance test tool. I think it can also run stand alone. What dynatrace did was that it showed a high degree of detail as to the timings of individual methods, number of threads, and other metrics which helped troubleshoot performance problems & memory leaks in our application.

this is a Joke right? If this was about, execution profilers don't help you to find memory leaks then I'd aggree. That said, I don't know how to find a memory leak *without* tooling. In my performance tuning course I teach people how to find a memory leak in any application in 5 minutes or less, guarneteed everytime.

I commented to early on this one. I see that the posting is an obvious troll. VisualVM has the exact feature needed to completely characterize a memory leak and these features are not turned on nor mentioned in the screenshot.

Finding a memory leak in dev/test environments is different to finding a memory leak in production. As has already been said, pretty much all profilers listed above can find memory leaks in dev/test environments, because being intrusive and introducing overhead doesn't matter so much. In production, it can be slightly different because profiling overhead can impact user response times and business activity, specficially for high throughput applications.

We've had probably 2-3 customers in the last year resolve real production memory leaks, more often than not OOM exceptions in production aren't leaks, which I've explained in a blog I wrote last year:

http://www.appdynamics.com/blog/2011/04/10/troubleshooting-outofmemory-exceptions-in-production/

To say profilers don't help you find memory leaks is pretty misleading.