I've got a running java webapp, that I'm monitoring with visualVM.
Here's the graph of the heap:
The was tested with two sets of requests, one at 3:20 and the other at 4:40 aprox (they are represented in the graph as the only two peaks).
My question is: does this means I have a memory leak? I'm worried about the middle part where, although the GC runs, the heap stays in 250MB all the time.
Thanks a lot for your insights.
Are you saying there were no requests before 3:20? If so, than I would say I don't see any evidence of a leak.
I don't know your app, but it's typical (based on architecture/design) for some objects that hang around for the life of the JVM to become initialized when the app is used for the first time.
What JRE are you using? What heap/GC relevant parameters are passed to the application?
The peak isn't bad (if there was more todo for the server it makes sense that the peak increases). But what is looking not so good, that the level after 4:40 (when the load is low again) is higher as the level before load went up. But it doesn't need to be...
Now you should look into more detail, which objects or object-graphs are kept in heap. So do the same test run again including (with profiler):
Now you should analyze the diffs and whether you see weird objects, which should have been garbaged.
The first request at 3:20 caused some memory to be held, but notice that the GCs after the second request reclaimed most of it. Also I think that major GC was performed only after the second request at 4:40.
It looks like there is no leak. My theory is that the request at 3:20 caused the young generation to fill up, and the resulting minor GC promoted some objects to older generation. The next major GC, caused by the request at 4:40 cleaned most of those up.
You can verify this by using a profiler to mark the heap before issuing the same request as the one at 3:20, forcing a full GC, and then checking what objects are lingering. I am not sure if VisualVM lets you (1) mark the heap and (2) force a full GC, but OptimizeIt used to do it.
JvisualVM allows you to force a garbage collection.
Try using that to see what happens.
What do you mean by memory leak here? I don't think any good JVM implementaiton like SUN would have such a crazy bug. memory leak word is ideally used when you dont have reference to a memory location (zombie) or you dont have any possibility to reclaim it. If you have wrong programming practice where you hold reference to objects which are no longer in use and they in larger scope (lifespan) then you eat up more memory not giving the GC an option to re-collect it.