Possible memory leak?

Question

I have a working java webapp that I am tracking using visualVM .

Here's the heap graph:

heap http://www.freeimagehosting.net/uploads/9bb3841450.png

The test was tested with two sets of queries: one at 3:20, the other at 4:40 aprox (they are presented on the graph as two peaks).

My question is: does this mean that I have a memory leak? I'm worried about the middle part, where although the GC works, the heap stays at 250 MB all the time.

Thanks so much for your ideas.

Answer 1

The first request at 3:20 made some memory hold, but note that the GC after the second request was most corrected. I also think that the main GC was executed only after the second request at 4:40.

There seems to be no leak. My theory is that the request at 3:20 made the younger generation fill up, and the received younger GC promoted some objects to the older generation. The next major GC, triggered by a request at 4:40, cleared most of them.

You can verify this using the profiler to mark the heap before issuing the same query as the one at 3:20, forcing a full GC, and then checking which objects are delayed. I'm not sure if VisualVM allows you to (1) flag a bunch and (2) force the use of the full GC, but OptimizeIt is used for this.

Answer 2

You say there were no requests until 3:20? If so, then I would not say that I do not see any signs of a leak.

I do not know your application, but it is typical (based on architecture / design) for some objects that freeze during the life of the JVM to initialize when the application is used for the first time.

Answer 3

Which JRE are you using? What parameters for the heap / GC are passed to the application?

The peak is not bad (if the server had more todo, it makes sense to increase the peak). But what doesn’t look very good is that the level after 4:40 (when the load is back again) is higher than the level before loading. But this is optional...

You should now examine in more detail which objects or graphic objects are stored on the heap. So, repeat the same tests, including (with the profiler):

• take a picture of the heap before the load rises.
• take a picture of the heap after the load drops (make sure to manually synchronize the GC)

Now you have to analyze the differences and see if you find strange objects that were supposed to be trash.

Answer 4

JvisualVM allows you to force garbage collection.

Try using this to find out what will happen.

Answer 5

What do you mean by memory leak here? I don’t think that any good JVM implementation like SUN will have such a crazy mistake. The word memory leak is ideally used when you do not have a link to a memory cell (zombie), or you do not have the opportunity to return it. If you have the wrong programming practice, when you keep a reference to objects that are no longer used, and they are more (lifespan), then you eat more memory, preventing the GC from reassembling it.