CODEWITHSUNDEEP
javamemory-leaksjvisualvm
Jason
Jason

Reputation: 2197

using Jvisualvm to detect memory leaks

My java jar is just one of many that a larger program uses. I am trying to determine if my code is the cause of a memory leak, or if there are other problems outside of my code. I am using jvisualvm, and have identified all of my classes, and none of them seem suspect. Looking at the sampler, i can see that byte[], char[], and int[] appear to be biggest users in terms of size and instances created. the problem is, that i can't determine who they belong to. I know that i have various byte[] in my program, but since there are some 32,000 instances, it is hard to determine the source looking at them one by one. Is there a way to filter the data so that only items originating from a certain jar or area can be viewed? Thanks.

Upvotes: 2

Views: 2813

Answers (1)

BunjiquoBianco
BunjiquoBianco

Reputation: 2034

Unless you know you are creating a lot of byte[] or String instances, I wouldn't put money on byte[] or char[] being the source of the issue. Pretty much every heap I've dug through has loads of these as they're used in many bits of java's internals. I'm not saying that they can't be the issue, but it's more fruitful to first concentrate on unusual amounts of objects you know you are creating, even if they aren't the biggest things in the heap.

I personally found MAT better for analysis work than VisualVM, although VisualVM is great for monitoring memory usage on the fly and watching GC cycles.

MAT also allows you to drill down to see incoming and outgoing reference to the retained objects. This will give you a better picture of which objects are holding onto more memory than you expect and should help you to find out whether one of the objects from your JAR is the culprit.

The help documentation included with MAT is pretty good and definitely worth a read to help get you started.

If you want to get even further into the rabbit hole read up on OQL which you can use to query the heap in both MAT and VisualVM.

MAT can be found here: http://www.eclipse.org/mat/

I dug out some background reading (some of which is a bit dated, but still relevant to paint a better picture of how to approach the problem)

Leaks are easy to find, but memory usage analysis is bit more difficult
Memory leaks are easy to find
Finding memory leaks with SAP memory analyser

It's also worth understanding a bit about GC when looking at the heap so worth a flick through these:
GC Tuning
Diagnosing a Garbage Collection problem

Upvotes: 2

Related Questions